They often bypass the normal joiner-mover-leaver and recertification cycle. If there is no authoritative sync, access remains valid after a user leaves, changes role, or a vendor relationship ends. The risk grows further when credentials are shared or when local administrators can create exceptions without central visibility.
Why legacy platforms and shadow SaaS keep access alive
Legacy platforms and shadow saas create persistent access risk because they sit outside the control points that normally close access when a person or vendor relationship changes. The access may still work even after HR, procurement, or the central IAM process believes it has been removed, which means entitlement drift can quietly outlast the business relationship that justified it.
That persistence is often reinforced by OAuth 2.0 Authorization Framework style delegated access, where a stale client, app consent, or long-lived token remains valid until someone explicitly revokes it. In practice, the risk is not only forgotten logins, but also the hidden trust path that keeps the application or integration operating after the original owner has moved on.
Where the access-control failure usually sits
The control failure is usually not one big break, but several smaller gaps that line up: no authoritative synchronisation, no timely recertification, and no clean offboarding for local accounts, shared logins, or vendor-managed integrations. Legacy systems often store their own user records, while shadow SaaS lets business units provision access directly, so the central record and the actual access state diverge.
That gap is especially hard to see when administrators can create exceptions locally or when a team treats a shared credential as a quick workaround for operational continuity. A platform that still “works” after the formal process says access is gone is usually signalling that revocation is weak, not that the risk has disappeared.
For a broader control lens, the issue aligns with access governance and least-privilege disciplines in CIS Controls v8 and NIST SP 800-53 Rev 5 Security and Privacy Controls, because both frameworks expect access to be inventoried, reviewed, and removed when it is no longer justified.
Why the risk persists even when nobody is actively abusing it
Persistent access is dangerous because dormant access is still usable access. If an account, token, or local admin path remains valid, an attacker only needs one later opportunity, such as credential theft, vendor compromise, or an insider mistake, to turn an old exception into a live entry point.
That is why the problem is not limited to immediate compromise. It also increases blast radius, makes investigations harder, and leaves organisations unable to prove that removed staff, former contractors, or retired integrations truly lost access. Where the subject involves cloud or SaaS control gaps, the same pattern is reflected in cloud-governance expectations such as ISO/IEC 27001:2022 Information Security Management, which expects organisations to control access, privileged access, and authentication consistently across environments.
Risk and Threat Considerations
Persistent access becomes most serious when a stale account, shared secret, or unmanaged vendor connection can still reach sensitive systems without central oversight. The exposure is often invisible until an audit, incident, or offboarding review reveals that access outlived the business need.
Failure mechanism: Legacy systems and shadow SaaS bypass authoritative lifecycle controls, so revocation never reaches every place where access was created, inherited, or cached.
Impact: Former users, contractors, vendors, or compromised credentials can continue to access data and systems long after the relationship ended, increasing the chance of misuse, persistence, and hard-to-detect intrusion.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-6 — Access Control Management | Persistent access arises when accounts and exceptions are not removed on time. |
| Recommendation — Inventory access paths and remove stale accounts, shared logins, and exceptions promptly. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Long-lived secrets and stale credentials keep legacy and shadow access usable. |
| Recommendation — Rotate, revoke, and expire authenticators that no longer have a valid business owner. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The subject is about uncontrolled access persisting beyond its justified lifecycle. |
| Recommendation — Enforce centralized access approval, review, and removal across all platforms. | ||
Practitioner Guidance
What to verify: Confirm where access is created locally, where it is federated, and where it is only assumed to be governed centrally. The key question is whether offboarding and recertification actually remove the ability to authenticate, not just the record that someone should no longer have access.
Common mistake: Treating “no complaints” as evidence that access has been cleaned up. Quiet systems often hide the highest-risk exceptions, especially when shared credentials or vendor-managed consoles are involved.
Decision rule: If a platform can still authenticate after a user leaves or a contract ends, prioritise access inventory and revocation paths before cosmetic cleanup. If you cannot prove removal, assume the access still exists until the platform owner demonstrates otherwise.
Practitioner takeaway: Persistent-access problems are usually lifecycle failures, not just configuration errors, so the real control objective is provable revocation across every system that can still honour an old credential or exception.