Because access usually accumulates through role change, app sprawl, and incomplete offboarding. Strong authentication protects the entry point, but excessive entitlements persist when lifecycle processes do not continuously reconcile who the user is, what role they hold, and which permissions remain justified.
Why strong authentication does not stop access creep
Strong authentication answers the question “who are you?” at sign-in, but excess access is usually created by what happens after sign-in. When people change teams, gain temporary exceptions, or accumulate app-specific permissions over time, the account remains valid while the permission set quietly expands. The control failure is usually in entitlement lifecycle management, not login strength.
Access also drifts because organisations treat provisioning as a one-time event instead of a living state. If joiner-mover-leaver processes do not continuously reconcile role, ownership, and business need, a user can keep permissions that were once justified but are no longer needed. IAM and IGA Basics is a useful reference point for the difference between authentication, authorization, provisioning, and access review.
This is why “strong auth” and “too much access” can coexist. Authentication reduces the chance of account takeover, but it does not remove stale entitlements, inherited role memberships, orphaned app access, or permissions granted for a past project. Access Reviews and Certification Guide is especially relevant here because access recertification is the mechanism that catches privilege creep before it becomes normalised.
Where entitlement drift usually comes from
Most excess access comes from a few repeatable patterns. Role changes often add permissions faster than they remove old ones, so a user becomes the sum of multiple past jobs. Application sprawl makes this worse because each system has its own local grants, and no single process always owns the full picture. Exceptions for urgency, testing, or manager approval then become permanent because nobody revalidates them.
Offboarding gaps are another common source. A person may leave a team, change function, or move to a new employer relationship, yet their access survives in one or more systems. That is especially dangerous when permissions are tied to shared service workflows, delegated admin rights, or legacy applications that are outside normal review cycles. In practice, the problem is less about one bad access grant and more about many small failures to remove what no longer matches the person’s current job.
Strong authentication can even hide the problem by creating a false sense of control. If the sign-in looks modern and the MFA is working, teams may assume the account is safe, while the real issue is that the account is still authorized to do far more than it should. That is why the relevant question is not only whether the user can enter, but whether they should still be able to reach each resource after entry.
Why the fix belongs in lifecycle and authorization, not just login
The right control objective is continuous authorization hygiene. Access should be tied to a current business role, a current owner, and a current justification, then removed when any of those change. Strong authentication helps prove the session belongs to the right person; lifecycle controls decide whether the permission remains valid at all. Without that second step, authentication only protects a broad and possibly outdated permission set.
For practitioners, the useful focus is on entitlement sources of truth, not on adding another sign-in step. If roles are coarse, review them for inheritance and exception creep. If applications manage access locally, make sure those grants are fed back into review and deprovisioning workflows. If access approvals are manual, check whether they are actually time-bound and whether they expire when the business need ends.
When the answer has to be operational, the best indicator is whether the organisation can explain every standing permission in plain business terms. If not, the access model is already drifting faster than the authentication model can protect it.
Risk and Threat Considerations
Excess access creates a larger blast radius even when passwords, MFA, or passkeys are strong. An attacker who compromises a legitimate account can do more damage when that account still carries old roles, stale app grants, or dormant administrative paths, and insiders can abuse the same overreach without needing to bypass authentication at all.
Failure mechanism: access is granted once, but never fully revalidated against current role, ownership, or business need. That leaves outdated entitlements in place across multiple systems, so the account remains authenticated while its authorization surface keeps growing.
Impact: compromise becomes easier to monetize, lateral movement becomes simpler, and removal becomes slower because responders must untangle accumulated permissions before they can contain the issue.
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 | AC-2 — Account Management | Directly addresses account lifecycle, provisioning, and removal of stale access. |
| AC-6 — Least Privilege | Excess access is a least-privilege failure even when authentication is strong. | |
| IA-5 — Authenticator Management | Strong authentication protects entry points, but credential lifecycle still affects access control hygiene. | |
| Recommendation — Review account assignments continuously and disable or revoke access when business need ends. Limit every account to the minimum permissions required for its current role. Manage authenticators separately from entitlement governance and rotate or revoke them promptly. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Covers access policy and authorization controls needed to prevent accumulated permissions. |
| A.5.18 — Access rights | Directly covers granting, reviewing, and removing access rights over time. | |
| Recommendation — Define access rules that align permissions with current business need and enforce periodic review. Ensure access rights are approved, reviewed, and revoked when roles change or end. | ||
Practitioner Guidance
What to prioritise: start with the access paths that combine high privilege, broad application reach, and weak ownership. Those are the entitlements most likely to survive role changes and the hardest to justify after the fact.
What to verify: confirm that joiner-mover-leaver events actually trigger entitlement updates, that each standing permission has a current owner, and that exceptions expire instead of lingering indefinitely. If your review process cannot show this, it is auditing paperwork rather than access.
Common mistake: treating successful MFA rollout as evidence that access is under control. Authentication can be excellent while authorization is still bloated, and those are different security problems.
Practitioner takeaway: the question is not whether users can sign in securely, but whether the permissions attached to that identity are still justified today, because stale authorization is what turns strong authentication into a false comfort.
Related resources from NHI Mgmt Group
- When does an NHI become too risky to keep as-is?
- What should organisations do when automated role assignment gives users too much access?
- Why can federated access create compliance risk even when authentication is strong?
- Why do identity migrations create access risk even when users keep the same jobs?