Customer Identity and Access Management (CIAM) is all about keeping sensitive data secure, making sure the right external users (customers, partners, suppliers) can do the right things, and keeping everything working as it should.
Most teams know about role-based access control (RBAC). Some use policy-based access control (PBAC) too. At Veriam, we added another piece to the puzzle: subscription-based access control (SBAC).
These aren’t competing models, they solve different parts of the same challenge. In fact, some setups even combine them.
Role-based access control (RBAC) is probably the most familiar model. It’s simple: users get access based on their role.
For example:
admin
can create, edit, and delete contentviewer
can only read itRBAC is a great fit when access can be grouped into clear permission levels that external users can assign to their team members.
Policy-based access control (PBAC) uses dynamic rules to give access. Instead of assigning access by pre-defined roles, it uses conditions and custom attributes, like location or whether an organizations has signed a required agreement.
Example:
"Allow access to report X if the user is in the EU and has accepted the DPA."
PBAC is powerful, especially when you need fine-grained control. But writing and maintaining policies can take work. And, you still need a way to manage what users are entitled to access.
Subscription-based access control (SBAC) ties access to a customer or partner plan.
Examples:
SBAC doesn’t enforce access by itself. It tells your system what a user is entitled to based on their plan, agreement, or subscription. RBAC or PBAC then enforces that access in your product, using the information SBAC provides.
SBAC makes sense when access depends on more than just roles or attributes.
This comes up a lot in:
You don’t need to choose just one.
Use RBAC or PBAC for access enforcement, and layer SBAC on top to define entitlements.
Here’s how they line up:
Model | Based on… | Best for… |
RBAC | Roles (e.g. admin, user) | Functional permissions |
PBAC | Rules and conditions | Complex, fine-grained logic |
SBAC | Plans, contracts, agreements | Managing the context of access control enforcement models |
Let’s say you run a SaaS platform that offers analytics dashboards.
SBAC isn’t an enforcement model. It doesn’t block or allow access directly.
Instead, it tells your system what features a user should have, based on what they’ve signed up for, like their plan, contract, or payment status.
It adds a missing link between your access system and your product or business logic.
✅ Works well with paid plans, legal agreements, usage tiers
✅ Helps align entitlements with what’s actually enforced
⚠️ Needs to be combined with RBAC/PBAC for full enforcement
Most teams need a mix of models to balance flexibility, clarity, and security.
SBAC fills a gap that’s often overlooked: tying access to the things people have opted into, signed, or paid for. It’s not a replacement for RBAC or PBAC. It’s a missing layer that makes your whole system smarter and more aligned with your product.
That’s why we built SBAC into Veriam. When identity, access, and subscriptions all speak the same language, everything gets simpler for you and your users.