Who is accountable when access remains unmanaged outside Entra?

Accountability should sit with the enterprise identity governance function, not the directory owner alone. When access is provisioned or reviewed outside the primary platform, the organisation still owns the risk, and governance teams must define how those systems are brought under one policy model.

Why This Matters for Security Teams

When access is granted, reviewed, or revoked outside Entra, the risk does not disappear, it becomes distributed across teams, scripts, and system owners who may not share the same approval model. That creates blind spots in entitlement review, exception handling, and evidence collection. The real issue is not which directory issued the access, but which function is accountable for proving it was governed.

For identity teams, this is where ownership gets blurred between platform administration and governance. The enterprise identity governance function must define the policy, the control points, and the escalation path, while the directory owner provides technical enforcement. NHIMG’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives and Top 10 NHI Issues both reflect the same pattern: fragmented ownership becomes an audit finding long before it becomes a technical outage. That aligns with the direction of the NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10, which both emphasise accountable governance over tool ownership. In practice, many security teams discover unmanaged access only after a review failure, not through deliberate control design.

How It Works in Practice

Accountability starts by separating operational custody from governance authority. Entra administrators may run the directory, but the enterprise identity governance function should own the policy that defines who can approve access, what evidence is required, how exceptions are time-bound, and when unmanaged access must be remediated. That means every non-Entra access path, whether in a legacy app, SaaS admin console, script-based workflow, or service account process, must be mapped to a control owner and a review cadence.

In practice, mature programmes use a single policy model with multiple enforcement points. A common pattern is to standardise request, approval, and certification logic in the governance layer, then integrate other directories and applications via connectors, APIs, or periodic reconciliation. Where direct integration is not possible, the fallback should be documented compensating controls such as periodic access attestations, log review, and exception expiry. NHIMG’s NHI Lifecycle Management Guide is useful here because unmanaged access is often a lifecycle failure, not just a provisioning failure.

• Assign one accountable governance owner for all access paths, even if systems are outside Entra.
• Require every exception to have an expiry date, approver, and review trigger.
• Reconcile external entitlements back to the authoritative policy model on a fixed schedule.
• Escalate orphaned access to the business owner, not just the directory team.

This also matters for secrets and service accounts, where unmanaged credentials can persist long after the original owner has left. NHIMG research in The State of Secrets in AppSec shows that organisations still take an average of 27 days to remediate a leaked secret, which highlights how long unmanaged access can linger when ownership is unclear. These controls tend to break down when access is spread across acquired businesses, unmanaged SaaS tools, and application-specific admin stores because the governance team cannot reconcile entitlements fast enough.

Common Variations and Edge Cases

Tighter central governance often increases operational overhead, so organisations have to balance auditability against delivery speed. That tradeoff becomes most visible where business units insist on local admin autonomy or where a legacy platform cannot support modern lifecycle automation.

There is no universal standard for every edge case, but current guidance suggests treating each exception as a risk acceptance decision rather than a hidden operating norm. A system may remain outside Entra temporarily if integration is not feasible, yet accountability still sits with the enterprise function that can evidence control coverage. For high-risk applications, the control should be stronger: shorter review intervals, named business owners, and explicit removal triggers. For low-risk utilities, lighter review may be acceptable if compensating controls are documented and tested.

Two common failure modes deserve attention. First, teams assume the local application owner is accountable because they can approve access, but approval authority is not the same as governance ownership. Second, organisations rely on manual attestations without reconciling them to actual entitlements, which creates a false sense of control. The most reliable approach is to treat unmanaged access as an inventory problem and a governance problem at the same time, then bring it under one policy model before exceptions become permanent. That is especially important when external systems proliferate faster than the identity team can standardise them.

Related resources from NHI Mgmt Group

• Who should be accountable for revoking shared credential access?
• Who is accountable when configuration drift causes an access failure or breach?
• Who should be accountable for access to a self-hosted credential store?
• Who should be accountable for privileged access when vendors and admins both use it?