What happens when access decisions are not linked to enforcement across legacy and custom systems?

When decisions are not linked to enforcement, teams can identify risk but still leave access unchanged. That gap is common where standard connectors and SCIM stop, especially in older or custom environments. Programmable enforcement closes the loop by turning review outcomes into provisioning or deprovisioning actions, so governance does not end at the recommendation stage.

When Governance Decisions Stop Short of Enforcement

Access review programmes only reduce exposure when the decision path reaches the control plane that actually grants, extends, or revokes access. In legacy and custom environments, that final step is often missing, so a removed entitlement in the review record leaves the live account, token, or service connection unchanged. The result is a governance process that can document risk without changing it. That gap matters most where older applications, bespoke integrations, and non-standard provisioning flows sit outside modern identity tooling.

NHIMG research on Ultimate Guide to NHIs shows that only 20% of organisations have formal processes for offboarding and revoking API keys, which illustrates how often review and enforcement remain disconnected in practice. When the decision does not trigger action, the organisation may believe access has been corrected while the actual exposure persists. In practice, many teams discover this only after a stale account, secret, or integration is still operational long after the review cycle has closed.

How It Works Across Older and Custom Systems

In modern identity stacks, a review outcome can flow through SCIM, workflow automation, or a governance platform into provisioning and deprovisioning. Legacy and custom systems break that chain because they may lack standard interfaces, use application-specific admin functions, or require manual changes by system owners. In those environments, access decisions need programmable enforcement, meaning the review result must be translated into an executable action rather than a policy note.

That can take several forms: disabling an account through an application API, expiring a token, rotating or revoking a secret, removing a custom role assignment, or submitting a controlled change ticket where no API exists. The important point is that the governance record and the enforcement record must be linked enough to prove the decision was carried out. Without that linkage, teams cannot distinguish between approved exceptions, delayed remediation, and unresolved over-privilege.

When a system supports automation, the deprovisioning action should be triggered directly from the review outcome.
When a system is custom-built, the enforcement path should be documented, testable, and owned by a named system operator.
When the system is too old for integration, teams need compensating controls such as scheduled attestations, manual closure evidence, and exception expiry.
When access involves secrets or machine credentials, enforcement must include rotation or revocation, not just account status changes.

OWASP’s Non-Human Identity Top 10 is useful here because the same enforcement gap often appears with service identities, tokens, and keys that do not follow human IAM workflows. These controls tend to break down when the enforcement step depends on manual handoffs across systems that were never designed to accept a machine-executed decision.

Common Failure Patterns and Governance Gaps

Tighter review processes often increase operational overhead, requiring organisations to balance cleaner governance against the friction of legacy remediation. The most common failure is treating access certification as evidence of control success even when no enforcement event occurred. Another is assuming a custom application is low risk because it is small or internal, when in fact it may hold persistent privileged access that no standard connector can touch.

There is also a practical distinction between visible non-compliance and hidden non-enforcement. A review dashboard can show approvals, denials, and exceptions, but those records are only meaningful if teams can verify downstream action. For older systems, that often means building a compensating evidence chain: who approved the removal, who executed it, when the change was confirmed, and what residual access remained until completion. NIST control guidance on access enforcement and account management is helpful as a baseline, but the harder question in custom estates is always whether the control can be executed at all, not whether it was documented.

Where the organisation has many bespoke applications, enforcement tends to degrade into periodic cleanup unless ownership, change windows, and exception expiry are explicit. That is why access governance in legacy environments often becomes a dependency problem before it becomes an identity problem.

Risk and Threat Considerations

The material risk is residual access: decisions can say an entitlement should be removed while the live path remains open. In legacy and custom environments, that creates prolonged exposure because access often persists through local roles, embedded secrets, stale service accounts, or manual exceptions that never get closed.

Failure mechanism: The control fails when the review workflow is disconnected from the system of record that enforces access. Attackers and insiders benefit from stale permissions because dormant accounts, unrotated credentials, and unmanaged custom integrations are harder to detect and easier to reuse than actively governed identities.

Impact: Organisations can retain unauthorised access after certification, lose trust in audit evidence, and leave attack paths open across systems that security teams assume were remediated. At scale, that becomes a persistence problem as much as a governance problem.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Non-Human Identity Top 10	NHI-01 — Secrets and Credential Management	Legacy enforcement gaps often leave service credentials or keys active after review.
	NHI-05 — Offboarding and Revocation	The core issue is removing access, not merely documenting a decision to remove it.
Recommendation — Link review outcomes to secret revocation and rotation for non-human access. Automate offboarding actions so denied access is actually removed from target systems.
NIST CSF 2.0	PR.AA-04 — Identity Management, Authentication, and Access Control	Access decisions need enforcement in the system that grants or maintains access.
Recommendation — Implement access control workflows that enforce review decisions in production systems.
CIS Controls v8	6.3 — Disable Dormant Accounts	Legacy systems often retain unused or unreviewed access after governance closes.
	5.3 — Account Management	Custom systems need accountable account lifecycle handling, not just review records.
Recommendation — Disable or remove inactive access as soon as it is no longer required. Maintain authoritative account lifecycle records and tie them to enforcement actions.
NIST SP 800-63	6.1 — Proofing and Enrollment Requirements	Where enforcement depends on trusted identity records, lifecycle integrity matters.
Recommendation — Use authoritative identity lifecycle processes to support reliable access revocation.

Practitioner Guidance

What to prioritise: Start with the systems that hold the most privileged or hardest-to-see access, especially custom applications, older platforms, and machine credentials that cannot be governed through standard connectors. If a review outcome cannot trigger a real change there, that system should be treated as a control gap, not a tooling inconvenience.

What to verify: For every non-standard system, confirm there is a testable enforcement path for revocation, disablement, or rotation, and that a closure record can be produced without manual reconstruction. If the only proof is a ticket comment or an approval record, the access may still be active.

Decision rule: If access can affect production data or privileged operations, require enforcement evidence before closing the review item; if no automated path exists, use an exception with expiry and named ownership rather than silent acceptance.

What practitioners underestimate: The gap is usually not the review itself but the translation layer between governance and action. The objective is to make every important access decision observable, executable, and confirmable across systems that do not naturally speak the same identity language.

Practitioner takeaway: A good review programme does not end with a decision; it ends when the environment can prove the decision changed the live access state.