How do security teams know if unmanaged access is still active?

They should compare identity inventories, privileged access logs, and application-level permissions to look for accounts or entitlements that exist in practice but not in the governance catalogue. A persistent mismatch means the organisation is certifying a partial estate. The strongest signal is any access path that cannot be tied to a named owner and an approved lifecycle event.

Why This Matters for Security Teams

unmanaged access is not just an inventory problem. It is a control failure that leaves active credentials, entitlements, or service paths operating outside the governance catalogue. When identity inventories, privileged access management records, and application permissions do not reconcile, the organisation may be certifying a partial estate while attackers exploit the gap. Current guidance from the OWASP Non-Human Identity Top 10 and the NIST Cybersecurity Framework 2.0 both point to visibility, access review, and continuous monitoring as core requirements, not optional hygiene.

NHI Management Group research shows the scale of the visibility gap: only 5.7% of organisations have full visibility into their service accounts, and 91.6% of secrets remain valid five days after notification, which means access often persists long after teams believe it has been removed. The practical risk is that unmanaged access becomes an invisible control plane for lateral movement, privilege escalation, and quiet reuse. In practice, many security teams encounter it only after a breach or audit exception has already exposed the missing owner.

How It Works in Practice

Teams usually confirm unmanaged access by correlating three evidence streams: the identity inventory, privileged access logs, and application-level permissions. If an account exists in production but not in the governance catalogue, or if an entitlement is still active without a named owner and lifecycle event, that is a strong indicator of shadow access. The most reliable approach is continuous reconciliation rather than annual attestation. NHI Management Group’s Ultimate Guide to NHIs and Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs both emphasise lifecycle visibility as the basis for revocation, rotation, and offboarding.

• Compare cloud IAM, PAM, CI/CD, SaaS, and application ACLs against the approved registry.
• Flag any credential, token, or service account without a documented owner, purpose, or expiry.
• Check whether access was issued through JIT or remains standing beyond the approved task window.
• Validate that revocation events actually propagated to downstream systems and cached sessions.
• Review logs for unused but still valid secrets, especially for third-party integrations and OAuth apps.

For automation, policy checks should run at request time and during scheduled reconciliation, using the same source of truth for ownership and expiry. Best practice is evolving, but the direction is clear: static reports are not enough when access changes faster than certification cycles. Teams should also use the Top 10 NHI Issues as a checklist for rotation, logging, and offboarding gaps. These controls tend to break down in hybrid estates with multiple SaaS tenants and unmanaged third-party OAuth apps because the same entitlement can be duplicated, inherited, or reissued outside central controls.

Common Variations and Edge Cases

Tighter access reconciliation often increases operational overhead, requiring organisations to balance stronger assurance against the cost of chasing false positives. That tradeoff matters because not every mismatch means active abuse. Some are deliberate, such as break-glass accounts, vendor-maintained integrations, or temporary migration credentials. Guidance suggests these exceptions should still be time-bound, separately approved, and visible in the same review process rather than exempted from it.

The edge cases are usually environmental. Legacy applications may lack owner metadata, shared service accounts can mask true usage, and some secrets remain valid after a secret manager update because the downstream application never reloaded them. Third-party OAuth connections are especially problematic because visibility is often partial, and that makes it difficult to determine whether access is still active or merely dormant. NHI Management Group’s Ultimate Guide to NHIs — Key Challenges and Risks and Ultimate Guide to NHIs — Regulatory and Audit Perspectives are useful references for defining audit-ready evidence. The most defensible stance is simple: if access cannot be tied to an owner, expiry, and approved lifecycle event, it should be treated as unmanaged until proven otherwise.

Related resources from NHI Mgmt Group

• How do security teams know whether delegated Active Directory permissions are creating hidden risk?
• How do security teams know if merger access controls are working?
• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?