SaaS access control is the set of mechanisms that decide who can sign in to your product, what each person can do once inside, and how those rights change when people join, move or leave a customer organization. Done well, it rests on three layers: authentication, authorization and account lifecycle management. Done badly, it stalls enterprise deals and creates the kind of cross-tenant incident that no roadmap item can offset.

This guide is written for CEOs, VPs of engineering and engineering directors who own a multi-tenant product. It covers the RBAC vs ABAC decision, the tenant boundary, SSO and SCIM, audit logging, regulated-sector expectations in Poland and the EU, and how access rules connect to billing plans.

TL;DR

• Treat access control as three layers: authentication (SAML/OIDC), authorization (RBAC, ABAC or both) and lifecycle (SCIM provisioning and deprovisioning).
• Use RBAC for stable, job-based entitlements and reserve ABAC for contextual exceptions such as tenant, data classification or subscription tier. A hybrid avoids role explosion.
• Enterprise buyers see SSO and SCIM as baseline requirements. Missing them is a frequent reason procurement stalls.
• In regulated sectors in Poland, such as healthcare, expect centralized access management, SSO and immutable audit logs aligned with RODO (GDPR).
• Plan tiers and usage limits are authorization inputs. Design entitlements once, then let billing and access read from the same source.

The three layers of SaaS access control

The most useful way to scope the work is to split it into three layers, as SSOJet’s overview of SaaS identity management does:

1. Authentication: proving who the user is, typically through federation with the customer’s identity provider using SAML or OpenID Connect.
2. Authorization: deciding what that user may see and do.
3. Lifecycle management: creating, updating and removing accounts automatically, usually with SCIM.

Most teams over-invest in the second layer and under-invest in the first and third. Authorization is the part engineers enjoy designing. Authentication and lifecycle are the parts buyers ask about in the security questionnaire.

That gap matters commercially. According to the same source, about 80% of enterprise security reviews are typically cleared by supporting the major identity providers: Okta, Microsoft Entra ID and Google Workspace. It also describes SSO and SCIM as foundational for enterprise buyers, and names their absence as the most frequent cause of stalled enterprise procurement. Treat that as a practitioner’s observation rather than a universal statistic, but it matches what engineering leaders hear from sales.

RBAC vs ABAC: what each does well

Role-based access control (RBAC)

RBAC assigns permissions to roles and roles to users. An “Admin”, “Editor” or “Billing Manager” gets a defined set of actions. It is easy to explain to customers, easy to audit and cheap to evaluate.

Its weakness appears when real requirements depend on something other than job title. “Editors can edit documents, but only in their department, only while the document is in draft, and only if the tenant is on the Business plan.” Encoding that in roles produces “Editor-Finance-Draft-Business” and its many cousins.

Attribute-based access control (ABAC)

ABAC evaluates rules against attributes of the user, the resource, the action and the environment. NIST SP 800-162 defines ABAC as a model that grants or denies a request by evaluating rules against those attributes. That makes it well suited to contextual decisions: tenant ID, data classification, time of day, device posture or subscription tier.

The cost is complexity. Attribute-driven policies are harder to explain, harder to test and easier to get subtly wrong.

Side-by-side comparison

Why the hybrid usually wins

An academic comparison of the two models in multi-tenant cloud databases concluded that hybrid models are optimal for cloud-native environments, reporting up to 64% fewer unauthorized access attempts than standalone implementations. Read that figure as a result from one study with its own setup, not a guarantee for your product. The direction, however, agrees with practitioner advice.

The working split is simple. Use RBAC for broad, predictable entitlements. Layer ABAC on top for volatile exceptions such as tenant, department or subscription tier, as guidance on RBAC and ABAC in healthcare apps describes. The same guidance adds a condition worth pinning to the wall: keep both rule sets reviewable. If policy logic becomes too bespoke, the system may still work technically while becoming impossible to reason about.

Avoiding role explosion

Role explosion is the unmanageable growth of overly specific roles. It usually begins innocently: one enterprise customer needs a read-only finance role, another needs a regional manager, a third wants contractors limited to one project. Each request becomes a new role, and within a year nobody can say what the roles mean.

A few rules keep it under control:

• Cap the number of built-in roles. Start with three to five that map to real job functions.
• Move context out of role names. If a role name contains a region, a plan or a status, that is an attribute trying to escape.
• Make custom roles composable. Let customer admins combine permissions, but keep permissions, not roles, as the unit your code checks.
• Check permissions in code, never role names. can("invoice:approve") survives a reorganization. isFinanceManager() does not.
• Review quarterly. Delete roles nobody is assigned to and merge near-duplicates.

The tenant boundary comes first

In a multi-tenant product, the tenant boundary is the most important line in your authorization model. Security practitioners quoted by SSOJet describe identity management as a critical security control rather than a convenience, and point to misconfigured SSO and failed automated deprovisioning as leading causes of SaaS incidents.

Two design principles follow:

1. Make tenant scope part of every request, not an optional filter. The tenant identifier should be derived from the authenticated session and enforced at the data layer, so a missing WHERE tenant_id = ? in one query cannot leak data.
2. Scope identity configuration per tenant. Each customer brings its own identity provider, domains and session rules. A shared global setting is the fastest route to a cross-tenant login bug.

We have written a practical walkthrough of this problem, including how misrouted tenants cause outages, in tenant-scoped B2B SSO for developers.

SSO and SCIM: the enterprise baseline

SSO (SAML or OIDC) lets a customer’s employees sign in with the credentials and policies their IT team already controls: multi-factor authentication, conditional access, session length. For the buyer, it moves authentication risk back under their governance. For you, it removes password storage, resets and a large part of support load.

SCIM automates the joiner-mover-leaver lifecycle. When HR removes someone from the directory, their access to your product ends without a ticket. Without SCIM, deprovisioning depends on a customer admin remembering to log in to your admin console, and the forgotten account is exactly what auditors find.

Practical sequencing for a product that does not yet have either:

1. Ship OIDC and SAML federation per tenant, with enforced SSO as an option.
2. Add just-in-time provisioning so first logins create accounts with a default role.
3. Add SCIM for create, update and deactivate, mapping directory groups to your roles.
4. Add session revocation, so deactivation ends active sessions as well as future logins.

The support matrix should name Okta, Entra ID and Google Workspace explicitly, since those are what security questionnaires ask about.

Audit logs and regulated sectors in Poland

If you sell into healthcare, public administration, finance or legal, access control is also a documentation exercise. Polish healthcare is a clear example. The recommendations of the Centrum Systemów Informacyjnych Ochrony Zdrowia (CSIOZ) on security of electronic medical records include a dedicated access control chapter that assigns responsibility to both the medical facility and the SaaS provider, each within its own scope. In practice the document points toward centralized access management, single sign-on and audit logs that record every user action, in support of data confidentiality and RODO (GDPR) alignment.

What that means for a product team:

• Log who did what, to which record, when and from where. Include reads, not only writes, for sensitive data.
• Make logs tamper-resistant. Append-only storage with restricted deletion rights, and separate credentials for log administration.
• Give customers their own view. Tenant admins should be able to filter and export their own logs without contacting support.
• Map the shared responsibility. Document what you control (platform, tenant isolation) and what the customer controls (who gets which role).

For products that must meet sector rules, we advise involving compliance early. Our compliance consultancy work and our guide to compliance in IT outsourcing cover how to bring those requirements into the engineering plan instead of discovering them in a pre-sales audit. Legal and edtech products carry their own confidentiality and data-subject concerns, which is why we treat legal tech and edtech access models as domain-specific designs.

Entitlements, plans and billing

Readers often ask how access control relates to SaaS billing models. The link is the entitlement: the statement of what a tenant is allowed to use because of the plan it pays for. Seat limits, feature flags, API quotas and storage caps are all authorization decisions whose input is a billing fact.

Two patterns avoid trouble:

• One source of truth for entitlements. Billing writes plan and usage state. The authorization layer reads it as tenant attributes. Do not copy plan logic into feature code.
• Separate “may do” from “has paid for”. A user’s role says whether they may export data. The tenant’s plan says whether export exists at all. Evaluate both, and return a different error for each, so the UI can show an upgrade prompt rather than a permissions error.

This is where ABAC earns its place: subscription tier is a textbook tenant-level attribute. If you charge by consumption, the same logic applies to metered limits. Our playbook on usage-based billing for SaaS goes through how metering, limits and invoicing connect.

Access control for AI features

Adding an assistant or search over customer data creates a new authorization surface. A retrieval-augmented system that indexes documents without carrying their permissions can show one user content they could never open directly. The rule is that retrieval must filter by the same tenant and role or attribute checks as the rest of the product, before anything reaches the model.

That applies to enterprise search, copilots and LLM integrations alike. If you are planning this, see how we approach RAG and enterprise search development and secure LLM integration.

Our perspective

We see the same pattern when engineering leaders ask us to review a product that has outgrown its first permission model. The original design worked for ten customers. At fifty, with enterprise buyers asking for SSO, SCIM and audit exports, every change touches code in a dozen places.

Our view is that access control should be designed as a platform capability, not a feature. That means one policy decision point, permissions checked in code instead of role names, tenant scope derived from the session, and entitlements fed from billing. Teams that do this early spend less on rework and answer security questionnaires faster. Teams that postpone it end up retrofitting under deal pressure, which is the most expensive time to do it.

We also recommend a hybrid model in nearly every B2B case, with a strict rule that ABAC handles exceptions, not the whole policy. It keeps the customer-facing story simple (roles) while leaving room for the contextual rules enterprise customers eventually demand. When we audit an existing system, we start with three questions: where is the tenant boundary enforced, what happens when a user is removed from the customer directory, and can an auditor reconstruct who accessed a record last quarter?

— Vlad

Getting help with your access model

If your authorization layer is slowing enterprise deals or you are modernizing a legacy permission system, a focused technical review is usually the fastest first step. Our technical audit and technology consulting team can assess tenant isolation, SSO and SCIM coverage and audit logging, and our legacy system modernization team can carry the redesign through delivery. To discuss scope, start from our services overview and request a consultation.

A practical implementation checklist

1. Inventory every place the code checks a role name, and replace it with permission checks.
2. Confirm tenant ID comes from the authenticated session and is enforced in the data layer.
3. Define three to five built-in roles and write down what each can do.
4. List the attributes you will allow in policies: tenant, plan, data classification, department. Reject the rest until needed.
5. Ship per-tenant SAML and OIDC, then SCIM, then session revocation on deactivation.
6. Record read and write events for sensitive resources in append-only storage.
7. Feed plan and usage state from billing into the authorization layer.
8. Test cross-tenant access automatically on every release.

FAQ

What is the difference between RBAC and ABAC?

RBAC grants permissions based on a user’s role, such as admin or editor. ABAC evaluates attributes of the user, resource, action and environment, such as tenant, data classification or time. Most B2B SaaS products combine them: roles for broad entitlements, attributes for contextual exceptions.

Do I need SCIM if I already support SSO?

If you sell to enterprise customers, yes in most cases. SSO controls how people sign in, while SCIM controls whether their accounts exist at all. Without it, removing a leaver depends on a manual step in your admin console, which is a common audit finding.

How do I stop one tenant from seeing another tenant’s data?

Derive the tenant from the authenticated session, enforce it in the data access layer instead of individual queries, and scope identity settings per tenant. Add automated cross-tenant tests to your release pipeline so a regression is caught before customers see it.

How do billing plans connect to access control?

A plan defines entitlements, which are tenant-level attributes that authorization reads. Keep one source of truth for them in your billing system, and treat “not on your plan” as a different result from “your role does not allow it”.

Which rules apply to access control for healthcare SaaS in Poland?

CSIOZ recommendations for electronic medical records cover access control, centralized management, SSO and audit logging, in connection with RODO (GDPR). Check the current text with your legal and compliance advisers, since requirements depend on your exact role in processing the data.

Sources

• SSOJet
• Role-Based vs Attribute-Based Access Control in Multi-Tenant Database Security (IJRITCC)
• What should teams get right about RBAC and ABAC in healthcare apps? (NHIMG)
• CSIOZ recommendations on security of electronic medical records (ezdrowie.gov.pl)
• NIST SP 800-162 ABAC guide overview (archTIS)

Recommended

• Avoid 2 a.m. Outages: Tenant Scoped B2B SSO for Developers
• Usage-Based Billing for SaaS: A Practical Playbook