How Should Modern Enterprises Design Access Models Using RBAC, ABAC, and PBAC?
A practical comparison of role-based access control, attribute-based access control, and policy-based access control for modern enterprise environments.
Quick Verdict
A hybrid of all three serves as defence in depth for access control. Role-based access control (RBAC) provides baseline access to identities, attribute-based access control (ABAC) enhances the granularity of access provisioning, and policy-based access control (PBAC) applies real-time factors when granting access.
The evolution of access controls from RBAC to ABAC to PBAC reflects the change in the demands of modern enterprises. For example, 16% of companies globally are fully remote, with 63% offering a hybrid or remote-first option. This shift indicates a change in the technology needs of organisations: they need to share files, applications, and communications over a larger distance.
The threat landscape has prompted change in identity mechanisms, namely the increased sophistication of AI-enhanced social engineering campaigns. In the first half of 2025, identity-based attacks rose by 32%. Building phish-resistant identity mechanisms and preventative controls is essential in defending against this emerging trend.
Definitions
Access Control
Access control is a data security process that enables organisations to manage who is authorised to access corporate data and resources.
Attribute-Based Access Control (ABAC)
In ABAC models, access is granted flexibly based on a combination of attributes and environmental conditions, such as time and location. ABAC is the most granular access control model and helps reduce the number of role assignments.
Role-Based Access Control (RBAC)
In RBAC models, access rights are granted based on defined business functions, rather than individuals’ identity or seniority. The goal is to provide users only with the data they need to perform their jobs — and no more.
Policy-Based Access Control (PBAC)
Policy-based access control (PBAC) is a strategy to govern access to systems and resources based on the user’s role and an organisation’s policies.
Principle of Least Privilege
The principle of least privilege (PoLP) refers to an information security concept in which a user is given the minimum levels of access — or permissions — needed to perform their job functions. It is widely considered to be a cybersecurity best practice and is a fundamental step in protecting privileged access to high-value data and assets.
Privilege Creep
Privilege creep is the gradual accumulation of access rights that exceed what an individual needs to function in their current role.
Why Did Traditional Access Control Models Become Outdated?
Traditional access control consisted of role-based access, granting access based on the minimum level of access required to do your job. It was the enforcer of the least privilege concept, so to speak. The success of role-based access hinged on managing the joiners, movers, and leavers lifecycle in line with role-based access — i.e. revoking access in a timely manner and ensuring that access rights reflect the reality of the role.
Provided all this is met, this model easily works well for traditional enterprises, for example, a single geographic location, no work from home, and on-premise applications. As the needs of modern enterprises evolved — rapid expansion, globally distributed teams, and a variety of devices including BYOD — the role-based access control model did not account for everything.
Additionally, the threat landscape has evolved over the last decade with respect to malicious attack tools, for example, ransomware-for-hire and AI-enhanced attack methods, increasing accessibility for malicious actors.
Parallel to this, modern enterprises require seamless, secure access to applications, files, and devices. Offices may be on the move, and access may take place through multiple devices, corporate devices, and sometimes personal devices.
In the Zero Trust architecture, where identity has become the control plane, traditional access control models are no longer enough. The network perimeter is no longer trusted by default.
RBAC Table — Pros, Cons and Attacks Defended Against
| Category | Details |
|---|---|
| Pros |
Easy to understand and implement. Maps well to job roles, departments, and business functions. Supports baseline least privilege. Easier to audit than individually assigned permissions. Works well for stable organisational structures. Useful for standard access provisioning during joiner, mover, and leaver processes. |
| Cons |
Can become rigid as the organisation grows. Can lead to role explosion when too many variations are created. Roles can become overly broad over time. Does not naturally consider device, location, risk, time, or session context. Requires regular access reviews to prevent privilege creep. May not be flexible enough for cloud, SaaS, remote work, and dynamic collaboration models. |
| Attacks / Risks It Helps Defend Against |
Excessive individual permission assignment. Inconsistent access granting. Basic privilege creep when roles are reviewed properly. Unauthorised access caused by users being placed outside approved job functions. Audit failure caused by unclear access ownership. Accidental access to systems unrelated to a user’s job role. |
Attribute-Based Access Control
Attribute-based access control represents an advancement in access control models by considering the attributes of the identity requesting access. For example, it may consider the department and location as part of the access control decision.
| Attribute Category | Attribute Examples |
|---|---|
| User Attributes | Department, job title, employment type, seniority, region, manager, clearance level |
| Role Attributes | Business role, admin role, project role, temporary role, privileged role |
| Resource Attributes | Data classification, system type, application sensitivity, record owner, business unit, region |
| Device Attributes | Managed device, compliant device, encrypted device, patched device, trusted device, jailbroken or rooted status |
| Session Attributes | MFA status, session age, sign-in risk, authentication strength, token validity, session location |
| Network Attributes | IP address, corporate network, VPN status, country, impossible travel, anonymous proxy, TOR |
| Behaviour Attributes | Unusual download volume, abnormal login time, impossible travel, repeated failed attempts, new device behaviour |
| Time Attributes | Working hours, change window, contract dates, project dates, temporary access expiry |
| Business Context Attributes | Approved project, ticket reference, business purpose, data owner approval, customer assignment |
| Risk Attributes | User risk, device risk, session risk, application risk, data sensitivity, transaction risk |
| Compliance Attributes | Regulatory scope, data residency, retention policy, audit requirement, segregation of duties |
| Approval Attributes | Manager approval, data owner approval, security approval, PAM approval, emergency access approval |
| Lifecycle Attributes | Joiner status, mover status, leaver status, contract end date, account status, dormant account flag |
| Exception Attributes | Exception ID, exception owner, expiry date, risk acceptance, compensating control |
| Monitoring Attributes | Logging enabled, session recording enabled, alert status, audit trail available |
This model supports geographically diverse enterprises with globally distributed workforces. Attribute-based access control enables the assignment of access based on attributes. It is useful, but is probably more suitable for mid-sized enterprises due to the administrative overhead.
ABAC Table — Pros, Cons and Attacks Defended Against
| Category | Details |
|---|---|
| Pros |
Enables more granular access decisions. Considers user, role, resource, device, session, network, behaviour, time, business context, risk, compliance, approval, lifecycle, exception, and monitoring attributes. Supports geographically diverse enterprises with globally distributed workforces. Reduces the need to create excessive role variations. Allows access decisions to reflect context, not just job role. Useful where access depends on location, device posture, data sensitivity, or user attributes. |
| Cons |
Can create administrative overhead. Requires accurate and current attribute data. Requires governance over attribute sources and ownership. May be too complex for smaller organisations with simple access needs. Incorrect attributes can lead to incorrect access decisions. Requires ongoing review to ensure attributes still reflect business reality. |
| Attacks / Risks It Helps Defend Against |
Overly broad access caused by role-only decisions. Access from non-compliant or unmanaged devices. Access from inappropriate locations or networks. Access to resources outside the user’s approved region or business context. Contractor or temporary access continuing beyond approved dates. Sensitive data access without required contextual conditions. |
Use case for ABAC: geospatial data-sharing environments where context awareness and fine-grained decision making is required.
Policy-Based Access Control
Policy-based access control is the most sophisticated model for access control in my opinion, because it combines two questions:
1. Who is asking for access?
2. What is their risk rating?
PBAC checks the access rights of an identity, human or machine, then validates its current state, making it a point-in-time assessment. Access is granted in the context of the user’s qualities, device risk signals, and session risk.
It is responsive to evolution in risk, such as device degradation and anomalous behaviour. If a genuine user logs in and then experiences a session hijack attack by an adversary based in a faraway location, then in the RBAC model they may still be granted access. However, in the PBAC model, this activity would lead to a degradation in device or session signal due to impossible travel, and should lead to blocked access.
PBAC Table — Pros, Cons and Attacks Defended Against
| Category | Details |
|---|---|
| Pros |
Suitable for complex enterprise and Zero Trust environments. Combines roles, attributes, risk signals, business rules, and compliance requirements. Supports allow, deny, challenge, restrict, escalate, or revoke decisions. Can respond to device risk, session risk, user behaviour, and anomalous activity. Aligns access control with governance, policy, and risk appetite. Useful for privileged access, sensitive data, regulated environments, and high-risk applications. |
| Cons |
More advanced to implement and maintain. Requires clear policy ownership and governance. Needs reliable identity, device, logging, and risk signal integrations. Poorly designed policies can create user friction or access gaps. Requires ongoing review to prevent policy drift. Can become difficult to manage if policies are duplicated, inconsistent, or poorly documented. |
| Attacks / Risks It Helps Defend Against |
High-risk sign-ins. Session hijacking indicators. Impossible travel and anomalous login behaviour. Privileged access misuse. Access attempts from risky devices or networks. Data exfiltration patterns such as unusual downloads. Segregation of duties violations. Unapproved access to regulated or sensitive data. Continued access after device posture, session risk, or user behaviour changes. |
Policies Considered in PBAC
| Policy Area | What the Policy Controls | Example Access Decision |
|---|---|---|
| Identity Policy | Defines who the user is, how they authenticate, and whether their identity is trusted. | Allow access only if the user signs in through the approved identity provider and completes MFA. |
| Role Policy | Defines baseline access based on job role, department, business function, or assigned responsibility. | Allow Finance users to access finance applications based on their assigned role. |
| Attribute Policy | Defines access based on attributes such as department, location, employment type, clearance level, or region. | Allow access only if the user is in the Finance department and assigned to the UK region. |
| Device Compliance Policy | Controls whether access is allowed from managed, compliant, encrypted, and patched devices. | Block downloads from unmanaged devices but allow browser-only access. |
| Network and Location Policy | Controls access based on IP address, country, trusted network, VPN status, or risky location. | Require additional verification when a user signs in from an unfamiliar country. |
| Session Policy | Controls what happens during the session, including session length, re-authentication, download restrictions, and session termination. | End the session or require re-authentication if session risk increases. |
| Risk-Based Access Policy | Controls access based on user risk, sign-in risk, device risk, application risk, or transaction risk. | Allow low-risk access, require MFA for medium risk, and block high-risk access. |
| Data Classification Policy | Controls access based on whether data is public, internal, confidential, restricted, regulated, or highly sensitive. | Prevent external users from downloading restricted customer data. |
| Privileged Access Policy | Controls admin, elevated, or high-impact access to critical systems. | Require approval, MFA, session recording, and time-bound access before granting admin privileges. |
| Approval Policy | Defines when access requires manager approval, data owner approval, security approval, or privileged access approval. | Require data owner approval before granting access to confidential records. |
| Segregation of Duties Policy | Prevents users from holding conflicting permissions that could enable fraud, misuse, or control failure. | Prevent the same user from creating and approving supplier payments. |
| Third-Party Access Policy | Controls access for contractors, vendors, partners, suppliers, and external collaborators. | Allow vendor access only during contract dates, from approved locations, with MFA enabled. |
| Lifecycle Policy | Controls how access is granted, changed, reviewed, and removed during joiner, mover, and leaver processes. | Automatically revoke access when a user leaves or when their contract ends. |
| Exception Policy | Controls temporary or non-standard access that falls outside normal policy rules. | Allow temporary access only if there is a documented exception, risk acceptance, owner, and expiry date. |
| Monitoring and Logging Policy | Defines what access events must be logged, monitored, alerted on, or retained for audit purposes. | Permit privileged access only if session logging and monitoring are enabled. |
| Compliance Policy | Ensures access decisions meet regulatory, contractual, privacy, audit, or data residency requirements. | Restrict regulated customer data access to authorised users in approved jurisdictions. |
When to Use Each
RBAC is the baseline for granting identities the minimum level of access to carry out their roles.
ABAC acts as an enhancement to role-based access control, ensuring roles “qualify” for access based on attributes. However, if you’re relatively small in scale, it may be high administrative overhead for very little benefit.
PBAC provides context-specific data that can indicate real-time compromise and lead to faster response.
The response in model development follows changes to the needs in modern enterprises and the increased sophistication of identity-based attacks. Each model has specific use cases for benefiting an organisation; however, success is reliant on the implementation and surrounding governance.
Joiners, movers, and leavers (JML) represent a key identity risk, as lack of governance can lead to access creep and takeover of dormant accounts. Access models must be appropriately monitored for accuracy, including role permissions aligning with job roles, timely access reviews, and prompt revocation of access. A robust governance model will ensure that the agreed structure is followed.
Governance Model Comparison
| Governance Area | RBAC Governance Model | ABAC Governance Model | PBAC Governance Model |
|---|---|---|---|
| Primary Governance Question | Does this user still belong in this role? | Are the attributes being used for access decisions accurate and current? | Does the access request comply with approved policy, risk, and business rules? |
| Main Governance Focus | Role membership, role permissions, and role ownership. | User, device, resource, environment, and business attributes. | Policy ownership, policy logic, risk thresholds, enforcement rules, and exceptions. |
| Access Ownership | Role owners, system owners, application owners, or department managers. | Attribute owners, HR, IT, data owners, device management owners, and application owners. | Policy owners, security architects, risk owners, data owners, compliance teams, and business control owners. |
| Access Provisioning | Users are added to predefined roles based on job function or department. | Access is granted when required attributes match the access rule. | Access is granted, denied, challenged, restricted, or escalated based on policy conditions. |
| Joiner, Mover, Leaver Controls | Ensure users are added to the correct role, moved to the correct role, and removed from old roles. | Ensure attributes are updated when a user joins, changes role, changes location, changes employment type, or leaves. | Ensure policies respond to lifecycle events, including automatic revocation, approval changes, and exception expiry. |
| Review Process | Periodic access reviews of role membership and role permissions. | Periodic validation of attribute accuracy, source systems, resource classifications, and device compliance data. | Periodic review of policy effectiveness, risk rules, exception usage, enforcement outcomes, and audit evidence. |
| Key Risk | Privilege creep caused by users keeping roles they no longer need. | Incorrect access decisions caused by inaccurate, outdated, or poorly governed attributes. | Policy drift caused by policies no longer reflecting business reality, risk appetite, or compliance requirements. |
| Evidence Required | Role catalogue, role owner, user-role mapping, access review records, approval records, and removal evidence. | Attribute source records, attribute ownership, device compliance records, data classification records, and access decision logs. | Approved policies, policy change history, risk rules, exception records, access decision logs, alerts, and monitoring evidence. |
| Exception Management | Temporary role assignments should have an owner, justification, and expiry date. | Attribute-based exceptions should be documented where a user does not meet normal access conditions. | Policy exceptions should include business justification, risk acceptance, compensating controls, owner, and expiry date. |
| Best Governance Fit | Stable access environments with clear job roles and predictable permissions. | Dynamic environments where access depends on context, data sensitivity, device posture, location, or user attributes. | Complex enterprise, Zero Trust, regulated, privileged access, and risk-based access environments. |
References
Crossover: Companies using a global remote workforce
Microsoft Digital Defense Report 2025
Microsoft Security: What is access control?
Ping Identity: Policy-Based Access Control
UK Parliament Research Briefing: Cyber threats
Karimah.co.uk: Identity is the New Control Plane
Scientific Reports: Geospatial data-sharing access control use case