Skip to main content
Identity Authority
Category: Access Control Models

Access Model

Simply put

The evidence provided does not describe an identity and access management concept. All sources refer to the CMS ACCESS Model, a Medicare payment and care-delivery program for chronic-disease management, which is unrelated to identity, authentication, or authorization. A reliable IAM glossary definition cannot be produced from this evidence.

Formal definition

The supplied evidence packet exclusively documents the U.S. Centers for Medicare & Medicaid Services (CMS) ACCESS Model, a value-based, outcome-based payment framework for chronic care in Original Medicare. It contains no material relevant to access control models in IAM (for example RBAC, ABAC, PBAC, ReBAC, or MAC/DAC) or to runtime authorization concepts. Consequently, no accurate practitioner-level definition of an IAM 'Access Model' can be derived from these sources, and defining the term here would require fabricating information outside the evidence.

Why it matters

No IAM-relevant context can be established for this term from the provided evidence. Every source in the evidence digest describes the U.S. Centers for Medicare & Medicaid Services (CMS) ACCESS Model, a value-based Medicare payment program for chronic-disease management. None of these sources address identity, authentication, authorization, or access control in any information-security sense. Because the evidence base is entirely unrelated to identity and access management, it would be irresponsible to manufacture a rationale for why an IAM 'Access Model' matters using material that does not support such claims.

For practitioners, the practical takeaway is a cautionary one about term collision. 'Access model' is a phrase that appears across many unrelated domains, and a search that returns healthcare-payment results does not validate an IAM definition. Readers seeking guidance on IAM access control models should consult sources that specifically address models such as RBAC, ABAC, PBAC, ReBAC, or MAC/DAC, none of which are represented in this evidence. This entry is intentionally left without a substantive IAM definition rather than filled with fabricated detail.

Who it's relevant to

IAM practitioners seeking access control model guidance
The evidence provided does not support an IAM definition of this term. Security architects, IAM engineers, and identity governance leads researching access control models should disregard this evidence, which pertains to a Medicare payment program, and consult sources that specifically address models such as RBAC, ABAC, PBAC, ReBAC, or MAC/DAC.
Editors and glossary maintainers
This entry illustrates a term-collision problem: the phrase 'access model' returned sources about the CMS ACCESS Model, an unrelated healthcare initiative. Before publishing an IAM definition, replacement evidence drawn from identity and access management sources is required.

Inside Access Model

Subjects (Principals)
The entities requesting access, such as human users, service accounts, or workloads. An access model defines how subjects are identified and represented after authentication, distinct from the separate steps of identification and authentication that precede the authorization decision.
Resources (Objects)
The protected assets, applications, APIs, files, records, or data, to which access is granted or denied. The model specifies how resources are described so that authorization decisions can be evaluated against them.
Access Control Model Type
The underlying paradigm governing how decisions are made: RBAC (role-based), ABAC (attribute-based), PBAC (policy-based), ReBAC (relationship-based), or MAC/DAC. Each defines the primary inputs used to reach a decision, and no single model is universally superior; the appropriate choice depends on deployment context.
Permissions and Entitlements
The discrete operations a subject may perform on a resource (for example read, write, delete). In RBAC these are typically aggregated into roles; in ABAC and PBAC they are derived from attributes and policies evaluated at decision time.
Policies and Rules
The logic that maps subjects and their context to allowed or denied actions on resources. Policies are central to PBAC and ABAC and, depending on configuration, may incorporate attributes, relationships, or conditions.
Enforcement Components
Runtime elements that apply the model: the PDP (policy decision point) evaluates the request, the PEP (policy enforcement point) enforces the outcome, and the PIP (policy information point) supplies attributes. These runtime enforcement concerns are distinct from IGA lifecycle concerns such as provisioning and access certification.

Common questions

Answers to the questions practitioners most commonly ask about Access Model.

Is one access control model like RBAC or ABAC universally better than the others?
No. Each model fits different needs. RBAC (role-based) is typically straightforward to administer and audit when access maps cleanly to job functions, but can suffer role explosion in complex environments. ABAC (attribute-based) offers finer-grained, context-aware decisions at the cost of policy complexity. ReBAC (relationship-based) suits scenarios where access derives from relationships between entities. PBAC (policy-based) centralizes rules as policy. The appropriate choice depends on your governance requirements, scale, and deployment context, and many environments combine models rather than adopting one exclusively.
Does defining an access model handle both authenticating users and controlling what they can do?
No. An access model governs authorization, determining what an authenticated principal may do. It does not perform authentication (verifying who the principal is) or identification (asserting a claimed identity). In a typical access flow, identification and authentication happen first, and the access model is consulted afterward to make authorization decisions. Conflating these steps is a common source of design errors; the access model assumes an already-authenticated principal as its input.
How does an access model relate to runtime enforcement components like a PDP and PEP?
The access model defines the logic and structure of authorization decisions, while runtime components enforce it. In most deployments, a Policy Decision Point (PDP) evaluates requests against the model, a Policy Enforcement Point (PEP) intercepts access and applies the PDP's verdict, and a Policy Information Point (PIP) supplies attributes needed for evaluation. The model itself is the design; these components are the machinery that applies it at request time.
Where do identity governance concerns fit relative to the access model?
Identity governance and administration (IGA) concerns, provisioning, access reviews, certification, and segregation of duties, typically shape and validate the access model over time but operate separately from runtime enforcement. For example, an access review may certify that role assignments in an RBAC model remain appropriate, and SoD constraints may be expressed within the model's structure. These lifecycle activities administer and audit the model rather than making real-time access decisions.
How should attributes and relationships used by an access model be sourced and kept current?
Depending on the model and configuration, attributes may come from directories accessed via LDAP, from provisioning flows using SCIM, or from a PIP at decision time. Keeping this data accurate is essential, since an ABAC or ReBAC decision is only as reliable as the attributes or relationships it evaluates. Stale or inconsistent source data can produce incorrect authorization outcomes, so freshness, authoritative sourcing, and reconciliation between provisioning and decision-time data typically warrant explicit design attention.
Can more than one access model be combined in a single environment?
Yes, and this is common. Many deployments layer models, for example using RBAC for coarse-grained role assignment and ABAC for fine-grained, context-dependent conditions, or applying PBAC to express policy across both. The practical challenge is maintaining consistent, auditable decision logic across the combined models and ensuring the enforcement components can evaluate them coherently. The right combination depends on governance, scale, and enforcement capabilities in your specific context.

Common misconceptions

An access model determines who a user is.
An access model governs authorization, what an already-authenticated principal may do. Identification and authentication are separate, preceding steps. The model consumes the verified identity as an input; it does not perform the verification itself.
ABAC or PBAC is always a better choice than RBAC.
No access control model is universally superior. RBAC, ABAC, PBAC, ReBAC, and MAC/DAC each fit different requirements, and the appropriate model depends on the deployment context, the granularity needed, and operational and governance constraints.
Defining the access model handles the full identity lifecycle.
An access model primarily concerns how runtime access decisions are made and enforced. IGA activities such as provisioning, access reviews, certification, and segregation-of-duties enforcement are separate concerns and are not resolved simply by choosing an access model.

Best practices

Select the access control model (RBAC, ABAC, PBAC, ReBAC, or MAC/DAC) based on your specific granularity, scale, and governance requirements rather than defaulting to a single model as inherently best.
Keep authorization logic distinct from authentication, ensuring the model consumes an already-verified identity and does not attempt to re-verify who the principal is.
Separate runtime enforcement components (PDP, PEP, PIP) from IGA processes such as provisioning and access certification so that decision logic and lifecycle management remain independently managed.
Externalize policy evaluation to a PDP where feasible so that authorization rules can be updated without changing application code, keeping enforcement at the PEP consistent.
Document permissions, roles, attributes, and policies explicitly so access decisions are auditable and can be reviewed during access certifications.
Validate the model against realistic scenarios and, depending on configuration and vendor profile, confirm that decision inputs and enforcement points behave as intended before deployment.
Promotional banner highlighting failures found in PCI audits and how to spot the gaps