Because policy only matters when the platform can enforce it in the systems where access actually exists. If critical apps are outside the control plane, teams cannot reliably provision, recertify, or revoke access there, so the risk shifts from policy design to operational reach.
Why policy can be right and still fail operationally
Access policy defines intent, but incomplete integration determines where that intent can actually be enforced. If some apps, directories, or admin consoles sit outside the control plane, the organisation may have a clean rule set and still be unable to provision, recertify, or revoke access consistently. The exposure comes from the gap between governance design and system reach.
That gap matters because access risk is created by unmanaged execution points, not by policy text alone. A policy can say who should have access, but if the target system accepts local accounts, legacy credentials, or bypass paths, the effective access model becomes split across controlled and uncontrolled surfaces.
Incomplete integration also weakens accountability. When entitlement changes must be handled manually in disconnected systems, the team loses a single authoritative view of who has access, what changed, and whether removal actually propagated everywhere. That makes review evidence thinner and exception handling more likely to become permanent.
What changes when the control plane does not reach every application
Once integration is partial, the main security question shifts from authorisation design to operational consistency. A strong policy can still be undermined by orphaned accounts, delayed deprovisioning, duplicate identities, and stale permissions in systems that do not consume the central control plane. Those are lifecycle failures as much as access failures.
In practice, incomplete coverage usually shows up in three ways: access can be granted in one place but not another, revocation does not happen at the same speed everywhere, and recertification becomes evidence-based only for the integrated systems. That creates blind spots that are especially dangerous when high-value applications are outside normal joiner, mover, leaver workflows.
For a broader view of how different authorisation patterns affect enforceability, see NHIMG's Authorisation Models Guide. Where access is backed by real system enforcement, policy and control plane stay aligned; where integration is partial, the organisation is managing intent rather than control.
Why the risk compounds during change, review, and offboarding
Incomplete integration is most dangerous at lifecycle boundaries. During onboarding, teams may create parallel access paths to get work done quickly. During role changes, they may update the central directory but miss the downstream system. During offboarding, they may revoke the primary path while leaving an alternate account active.
That is why the risk persists even when policy is well written. The policy may describe the correct state, but the operational process cannot prove that every dependent system has converged to that state. In a large environment, even a small integration gap can become a repeatable exception pattern rather than a one-off failure.
If the missing integration involves secrets, vaults, or privileged cloud roles, the consequence can be immediate access retention after central revocation. NHIMG's Azure Key Vault Contributor escalation 2024 illustrates how a role that can modify access policy can also turn that policy into a privilege escalation path.
Risk and Threat Considerations
Incomplete integration creates a control gap that attackers and insiders can exploit by shifting from governed access paths to unmanaged ones. The problem is not only missed enforcement, but also the persistence of accounts, tokens, or local permissions that central policy no longer sees.
Failure mechanism: Access is approved or revoked in the master policy, but disconnected applications continue to trust local roles, legacy credentials, or manual exceptions, so the real access state diverges from the intended one.
Impact: Teams lose reliable revocation, recertification, and auditability, which increases the chance of unauthorized access, delayed containment, and repeated exception-based exposure.
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, CIS Controls v8 and OWASP ASVS set 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 | Incomplete integration breaks account lifecycle enforcement across systems. |
| IA-5 — Authenticator Management | Disconnected apps often retain unmanaged credentials or tokens after policy changes. | |
| AC-6 — Least Privilege | Partial integration leaves excess access in unmanaged applications. | |
| Recommendation — Centralize account lifecycle control and verify deprovisioning reaches every connected system. Inventory, rotate, and revoke authenticators wherever applications still accept them. Apply least privilege consistently across integrated and legacy access paths. | ||
| CIS Controls v8 | 5 — Account Management | Account governance fails when some applications are outside centralized enforcement. |
| Recommendation — Use one authoritative process to provision, review, and remove accounts everywhere. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Access policy only works when all in-scope systems enforce it. |
| Recommendation — Extend access control enforcement to every application that accepts users or credentials. | ||
| OWASP ASVS | V8 — Authorization | Disconnected integrations weaken authorization enforcement across application boundaries. |
| Recommendation — Verify that each application enforces authorization, not just accepts central policy. | ||
Practitioner Guidance
What to verify: Test the control plane against the actual application estate, not just the directory or IAM source of truth. The key question is whether every system that can grant access also consumes the same joiner, mover, leaver, and review process.
Decision rule: If an application can still authenticate users or service accounts after central deprovisioning, treat it as a live control failure, not a documentation issue. Prioritise integration or compensating controls before you rely on policy compliance language.
What good looks like: Access changes propagate through every material system, exceptions are time-bound and owned, and teams can produce evidence that revocation, not just approval, actually occurred.
Practitioner takeaway: Well-defined policy is necessary, but enforceability is the real security control, and any system outside the control plane should be treated as an active residual-risk source until proven otherwise.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org