Single-Tenant Versus Multitenant SaaS Solutions: When Does it Matter?

Written by Morey J. Haber, BeyondTrust

Today, there are many cloud-native, software-as-a-service (SaaS) solutions, built and optimized for the cloud, from which to choose. Yet, many competing solutions continue to tout themselves as “cloud-based”, even though they really represent just a lift and shift of their traditional software solution to the cloud. This latter rebranding and stretching of the meaning of cloud is pejoratively referred to as ‘cloud washing’.

When it comes down to it, if the price is right, the uptime measures up against a service level agreement, and the solution is secure, does it matter if the solution is truly ‘cloud-based’ in the strictest sense? Does it really matter if the solution is cloud-native and multitenant, or rather a reengineered version to work in the cloud as a single tenant?

Let’s step back a moment and review the definitions of single tenant and multitenant.

• A single-tenant solution refers to the installation of an application that does not share backend or database resources with another operating instance. The runtime and data is dedicated to a single company, department, or organization. A role-based access model is used to control permissions and isolate datasets.
• A multitenant solution shares common resources, including potentially a backend database to provide a logic separation of data and permissions to isolate information, configurations, and runtime from other logical groups of users and companies. Multitenancy provides a method to efficiently scale the solution. If multitenancy is properly implemented, resources can be shared, while preventing data bleed from one tenant to another by applying data and operational segmentation.

Traditional on-premise technologies are typically considered single-tenant solutions, while cloud-based solutions are generally thought of as multitenant. However, these are perceptions, not hard rules. Often, an organization’s actual usage of cloud applications blurs these concepts. For instance, when you subscribe to a SaaS multitenant solution, the shared resources behind your subscription are utilized by multiple other organizations ,but your custom coding and implementation may be a single tenant, representing a hybrid tenant environment.

With that aside let’s look at the benefits and security tradeoffs of single-tenant versus multi-tenant SaaS solutions. Embracing a multitenant SaaS solution means your company must forgo the following three security best practices:

1. Change control: A multitenant SaaS vendor controls when your version is upgraded and patched. They will provide a maintenance window for the upgrade. You will be forced to accept the changes—even if it is not within a desirable timeframe for your business. If the upgrade introduces an unwanted change (bug or incompatibility), there is no way to roll back the changes since multiple organizations are leveraging the same multitenant shared resources.
2. Security: With any multitenant solution, there is always a risk of data bleed or a vulnerability that spreads between the organizations sharing resources. This can even be true with a simple backend misconfiguration, or an insecure third-party add-on that undermines the security of the multitenant model. In essence, these types of negative cloud security events are outside the SaaS customer’s control.
3. Customization: Beyond a few multitenant SaaS vendors that have designed customization directly into their platform to create hybrid tenant environments, most multitenant solutions do not allow extensive customization to meet individual business requirements due to the number of shared resources they consume. While this may be perceived as an advantage to avoid customized obsolesce, it can also cause distribution and unnecessary rework when APIs or features become deprecated as the service releases newer versions.

Foregoing these three security practices is a tradeoff organizations must weigh in lieu of maintaining the hardware, operating system, maintenance and security patches for the solution compared to an on-premise instance, or a private cloud deployment.

Now, let’s look at how the same three security practices play out in a single-tenant SaaS solution:

1. Change control: In a single-tenant SaaS model, the end user can decide when to upgrade to a new version. They may also choose to skip a version altogether. A common risk here is waiting too long to upgrade and potentially operating with an end-of-support or end-of-life version. A SaaS-based single-tenant version needs to be managed within your current change control procedures and policy. This requires effort not normally associated with a SaaS solution—even if the upgrade is fully automated.
2. Security: Your SaaS-based single-tenant is your own. Any misconfigurations or missing security patches that need to be manually authorized can introduce unnecessary risk. While it is a SaaS-based solution, you still have the change control responsibilities of patching and maintenance, just like full versions, even though the vendor will fully automate their installation. Again, while this is probably fully automated, the organization will need to maintain this, just like any other application for patch management. Since the solution is a single-tenant, there is a very low risk of data bleed unless the hosting company themself gets compromised.
3. Customization: A single-tenant SaaS solution allows for the most possible customization since any changes will not affect any other tenants or organizations. However, there is a risk that compatibility with future versions might break when the version is upgraded. Luckily, since you can control the version, you can test customization before any upgrade and stay on an older version until you are ready.

So, what else is different between a single-tenant and multitenant SaaS solution? If the cost to the end user is acceptable, the choice of multitenant versus single tenant simply amounts to understanding the tradeoff between change control and acceptable security risk. If you always want to be on the latest version, either model is acceptable—you just have to manage the change control yourself.

If you want to customize the SaaS solution, the SaaS solution’s capabilities should be given the most importance, as opposed to the tenancy model. Hybrid, tenancy-based solutions are a good fit for this requirement.

And finally, let’s consider security. All SaaS solutions should allow automatic security patching, but the difference defers back to your change control requirements.

Ultimately, it is up to you decide if change control, security, and customization are that important when choosing a SaaS solution. While the vendors runtime cost should be lower with multitenant solutions, well-designed single tenant solutions can be just as cost effective for them, and for you.

About the Author

Morey J. Haber is the Chief Security Officer at BeyondTrust. He has more than 25 years of IT industry experience and has authored three books: Privileged Attack Vectors, Asset Attack Vectors, and Identity Attack Vectors. He is a founding member of the industry group Transparency in Cyber, and in 2020 was elected to the Identity Defined Security Alliance (IDSA) Executive Advisory Board. Morey currently oversees BeyondTrust security and governance for corporate and cloud based solutions and regularly consults for global periodicals and media. He originally joined BeyondTrust in 2012 as a part of the eEye Digital Security acquisition where he served as a Product Owner and Solutions Engineer since 2004. Prior to eEye, he was Beta Development Manager for Computer Associates, Inc. He began his career as Reliability and Maintainability Engineer for a government contractor building flight and training simulators. He earned a Bachelor of Science degree in Electrical Engineering from the State University of New York at Stony Brook.