Stable identity is the verified subject identifier that says who or what is making the request. Current permission is the real-time decision about whether that subject may do a specific action on a specific resource. Keeping those separate helps teams avoid stale access, brittle role design, and revocation gaps.
Why stable identity and current permission are not the same control
Stable identity is the anchor for IAM and IGA Basics: it tells the system which subject is requesting access and gives you something durable to authenticate, log, review, and govern. Current permission is the decision layer, where policy evaluates that subject against a specific action, resource, context, and sometimes time. Mixing the two creates access designs that are hard to change safely.
That separation matters because a verified identity can remain the same while the allowed action changes many times across a session, a workflow, or an environment. A role, group, entitlement, or policy result is therefore not a person or workload, it is the present answer to “may this subject do this now?” In practice, stable identity supports accountability, while permission controls exposure.
For practitioners, the useful mental model is “identity is the subject, permission is the outcome.” Authorisation Models Guide is the right place to compare how RBAC, ABAC, ReBAC, and policy-based access separate subject identity from the authorisation rule that is applied to it.
How the split shows up in real access decisions
Stable identity usually comes from authentication, enrolment, or an identity proofing event, then stays stable enough to support audit trails, approvals, and recertification. Current permission is more volatile. It can depend on role assignment, attributes, resource sensitivity, time of day, device posture, approval state, or a just-in-time elevation path. That volatility is deliberate, because not every authenticated subject should keep the same access all the time.
This is why “who you are” and “what you can do” must be treated as separate records. If you collapse them, teams start using group membership as a proxy for every access decision, which leads to role explosion, stale access, and exceptions that quietly become permanent. If you keep them separate, you can change access without changing identity, and you can revoke permission without breaking the subject’s continuity.
In broader governance terms, IAM and IGA Basics is the natural reference point for provisioning, access reviews, entitlement management, and joiner-mover-leaver workflows, because those processes operate on permissions and entitlements rather than on identity itself.
Why the distinction matters for revocation, least privilege, and auditability
Stable identity gives you a persistent reference for ownership and traceability. Current permission determines exposure at the moment of use. When the two are treated separately, revocation becomes much more precise: you can remove a permission, expire an elevation, or narrow a scope without deleting the identity or disrupting unrelated access. That is the practical foundation for least privilege and for avoiding revocation gaps.
The distinction also improves investigation quality. If a subject was validly identified but its permission was overbroad, the problem is authorisation drift, not authentication failure. If the identity itself is wrong, duplicated, or unowned, the issue sits earlier in the lifecycle. Those are different failure modes and they need different controls.
Current permission should therefore be treated as a live control decision, not as an identity attribute stored once and trusted forever. When teams need a broader access model for people, machines, or agents, a guide such as Privileged Access Management Guide helps show how time-bound access, session controls, and elevation workflows keep permission separate from stable identity.
Risk and Threat Considerations
When organisations blur stable identity and current permission, stale entitlements and inherited roles can survive long after the original business need has gone. That creates standing access that is broader than intended and makes revocation slower, especially where approvals were granted once but never revisited.
Failure mechanism: The subject remains validly identified while its permissions are left implicit, cached, or role-derived, so access persists after the need has changed. Attackers and insiders can then exploit excessive entitlements, privilege creep, or delayed deprovisioning to reach data or actions that should no longer be available.
Impact: Organisations get larger blast radius, weaker audit confidence, and more brittle offboarding and exception handling. In higher-risk environments, the same confusion can turn an apparently normal account into a persistent path for unauthorized action, lateral movement, or policy bypass.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Stable identity must be established before permissions are evaluated. |
| AC-6 — Least Privilege | Current permission should be narrower than stable identity and limited to need. | |
| AC-2 — Account Management | Separating identity from permission requires distinct lifecycle control over accounts and entitlements. | |
| Recommendation — Authenticate the subject before evaluating any access decision. Limit active permissions to the minimum required for the current action. Review, adjust, and revoke account access independently from identity records. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The topic is fundamentally about access decisions and control separation. |
| A.8.5 — Secure authentication | Stable identity depends on reliable authentication before permissions are applied. | |
| Recommendation — Define access rules separately from identity records and enforce them consistently. Use strong authentication to establish the subject before authorisation. | ||
Practitioner Guidance
What to verify: Check whether your system can answer three separate questions cleanly: who the subject is, what permissions are currently active, and what rule justified those permissions. If one report or token is doing all three jobs, the design is too coarse and will be hard to revoke or audit well.
Decision rule: If the identity is stable but the business need changes frequently, move the changing part into dynamic authorisation, not into the identity record. If access is high-risk, make the permission short-lived, explicit, and reviewable instead of relying on broad standing access.
Practitioner takeaway: Treat stable identity as the durable truth about the actor, and current permission as the time-sensitive truth about allowed action. The better your separation, the easier it is to enforce least privilege without breaking accountability.
Related resources from NHI Mgmt Group
- What is the difference between role based access control and ad hoc permission granting in identity governance?
- What is the difference between identity governance and ITSM for access control?
- What is the difference between OT network segmentation and identity-based access control?
- What is the difference between Kubernetes network policy and identity-based access control?