The control model breaks because the directory can only attest to centrally managed identities, not the fallback accounts, local stores, or embedded secrets that applications still use. That leaves a gap between policy intent and real enforcement, so teams end up certifying a cleaner picture than production actually contains.
Why the Directory-Only Model Fails
The directory becomes a control plane only for what it can see. If identity teams stop there, they govern centrally issued identities but miss the accounts, local credentials, and embedded application secrets that actually authorize production actions. The result is a split-brain model: policy is written against one inventory while enforcement happens through a larger, quieter estate that the directory never touches.
That mismatch matters because application estates often keep their own fallback paths for resilience, migration, legacy integration, and vendor connectivity. Those paths are convenient for operations, but they also create alternate control surfaces that sit outside normal certification, deprovisioning, and ownership workflows.
For practitioners, the key distinction is between directory assurance and estate assurance. Directory assurance tells you who is known centrally; estate assurance tells you whether all effective access paths are governed, rotated, and removed on time.
Where the Governance Gap Appears in Production
The gap usually shows up in three places: fallback admin accounts created during outages, application-local user stores that were never retired, and embedded secrets that authenticate services without appearing in the directory. Those assets can outlive the people and teams that created them, which means ownership, review cadence, and revocation become ambiguous even when directory records look clean.
This is why a directory-first certification process can certify the wrong thing. A team may approve access for all managed identities and still leave production reachable through unmanaged paths that were invisible to the review. The directory then becomes evidence of process completeness rather than evidence of actual enforcement.
Ultimate Guide to NHIs — What are Non-Human Identities is useful here because the real issue is not just human access, but every identity-bearing mechanism that can still act on a system when the directory does not.
What Changes for Security Operations and Assurance
Once the application estate is out of scope, several downstream controls weaken at the same time. Offboarding no longer guarantees removal of all access paths, access reviews become incomplete, and exception handling drifts into permanent exception status. In practice, that means incident responders may discover valid credentials long after the directory says access has been terminated.
The control failure is especially visible during audits and remediation programmes. Teams can prove that directory entries were reviewed, but they cannot prove that local accounts were removed, secrets were rotated, or application-specific stores were inventoried with equal rigour. That creates a false sense of closure and delays the point where hidden access is actually retired.
NHI Lifecycle Management Guide and Top 10 NHI Issues both map well to this operational reality because lifecycle governance breaks down fastest when discovery, ownership, rotation, and offboarding stop at the directory boundary.
How to Rebuild the Control Model
The fix is to govern effective access, not just directory objects. That means inventorying application-local accounts, service credentials, API keys, certificates, tokens, and any embedded secret that can still authenticate or authorize action. Only then can the directory be treated as one source of identity data rather than the whole control model.
Identity Security Programme Guide helps frame the operating model question: who owns application identities, who approves non-directory exceptions, and who is accountable for removal when systems are decommissioned or refactored. When that ownership is unclear, hidden access persists even after central governance looks complete.
Directory governance should therefore be paired with estate discovery, secret inventory, and application ownership mapping. Without those three, certification becomes a paperwork exercise instead of a reliable control over production access.
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 addresses the attack surface, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Hidden app accounts and secrets survive directory offboarding. |
| NHI-02 — Secret Leakage | Embedded secrets bypass directory governance and remain active. | |
| NHI-07 — Long-Lived Secrets | Application secrets often outlast managed directory identities. | |
| Recommendation — Inventory non-directory accounts and revoke them during deprovisioning. Discover and rotate application secrets outside the directory. Set expiry and rotation for every application credential. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential lifecycle control is central when access lives beyond the directory. |
| AC-2 — Account Management | Accounts outside the directory still require lifecycle governance and review. | |
| AU-2 — Event Logging | Undiscovered application access paths weaken visibility and auditability. | |
| Recommendation — Manage, rotate, and revoke authenticators across the application estate. Maintain a complete account inventory and remove stale accounts promptly. Log authentication events from local stores and service credentials. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Access must be governed across the full estate, not only centrally. |
| A.5.18 — Access rights | Access rights need review and removal where directory controls do not reach. | |
| Recommendation — Extend access control policy to application-local and fallback accounts. Review and revoke application access rights on the same cadence as directory access. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account inventory and lifecycle management must cover non-directory accounts. |
| Recommendation — Track and disable local and shared accounts across applications. | ||
Practitioner Guidance
What to prioritise: Start with the application estate that can still reach production, especially legacy services, shared platform components, and emergency access paths. If a system can authenticate outside the directory, it belongs in scope for review and removal planning.
What to verify: Require evidence of local account discovery, secret inventory, and revocation proof, not just directory attestation. A clean directory export is not enough if you cannot show where fallback access was eliminated.
Common mistake: Treating “managed in the directory” as equivalent to “governed in production.” That shortcut hides the very access paths that tend to survive migrations, outages, and application refactors.
Practitioner takeaway: The control objective is to make every effective access path visible and accountable, because governance that stops at the directory only certifies the known part of the estate.
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 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org