The business owner of the application and the identity team share accountability, but the application owner must prove that access was removed. Governance fails when nobody can evidence revocation outside the IdP. Frameworks such as NIST CSF and NIST SP 800-53 both expect controlled access and verified revocation.
Why This Matters for Security Teams
Access that lingers in unmanaged applications is not just an IT hygiene issue. It creates a governance gap where nobody can prove who granted the access, who approved it, or who removed it. That is why ownership matters: the business owner understands the application risk, while the identity team controls the access lifecycle. NHI Management Group’s Ultimate Guide to NHIs notes that only 20% of organisations have formal processes for offboarding and revoking API keys, which is a strong signal that revocation failure is common, not exceptional.
Practitioners often assume the IdP is the whole story, but unmanaged apps, local accounts, embedded secrets, and direct grants outside the IdP can leave standing access behind. NIST’s Cybersecurity Framework 2.0 and NIST SP 800-53 both treat access control as something that must be operated and verified, not merely assigned. In practice, many security teams only discover orphaned entitlements after an audit, incident, or offboarding dispute has already exposed the gap.
How It Works in Practice
Accountability should follow the control plane and the system of record. The application owner is accountable for business justification, access reviews, and evidence that access was removed. The identity team is accountable for the lifecycle mechanics, including joiner-mover-leaver workflows, access request controls, and monitoring for stale entitlements. If an application is unmanaged, the identity team cannot be the sole owner of revocation because it may not control the app’s native accounts, embedded tokens, or external admin consoles.
In a clean operating model, the application owner must be able to show that access removal happened in the application itself, not only in the IdP. That usually means:
- maintaining an authoritative list of applications and their access methods
- documenting who can approve, revoke, and regrant access
- capturing revocation evidence from logs, tickets, screenshots, or API records
- reconciling IdP changes with app-native permissions on a scheduled basis
For NHI-heavy environments, this is especially important because access may be tied to service accounts, API keys, or embedded credentials rather than human sign-in. The Ultimate Guide to NHIs – Lifecycle Processes for Managing NHIs and the OWASP Non-Human Identity Top 10 both reinforce the need to manage lifecycle, rotation, and revocation as a coordinated control, not an afterthought. This guidance breaks down when an application has no API, no audit logs, and no documented admin path because revocation then depends on manual tribal knowledge.
Common Variations and Edge Cases
Tighter access governance often increases operational overhead, requiring organisations to balance provable revocation against the speed of business application changes. That tradeoff becomes sharper in shadow IT, SaaS sprawl, and legacy tools where the business can create access faster than central identity teams can observe it.
There is no universal standard for ownership in unmanaged apps, but current guidance suggests a simple principle: if the app team can create or remove access inside the application, it must own evidence of that action. If the identity team only manages the IdP layer, it should still own reconciliation and exception handling, but not be held solely accountable for access the IdP cannot touch. NHI Management Group’s Ultimate Guide to NHIs – Regulatory and Audit Perspectives is useful here because auditors will expect a complete control story, not a partial one.
Edge cases include third-party admins, locally provisioned service accounts, and applications with no deprovisioning API. In those cases, best practice is evolving toward explicit compensating controls, such as monthly access attestations, break-glass approval records, and reconciliation reports. NIST SP 800-53 and the Ultimate Guide to NHIs both support the expectation that access removal must be demonstrable, not assumed.
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 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | Directly addresses access control ownership and enforcement across unmanaged apps. |
| OWASP Non-Human Identity Top 10 | NHI-05 | Covers lifecycle gaps where service account access is left behind. |
| NIST SP 800-63 | Supports identity proofing and lifecycle assurance, relevant to account revocation accountability. | |
| OWASP Agentic AI Top 10 | Relevant where unmanaged apps are accessed by autonomous agents or tool-using workloads. | |
| NIST AI RMF | GOVERN-2 | Ownership and accountability are central when AI-driven workflows create access risk. |
Use lifecycle controls to ensure identities and credentials are retired where access is no longer justified.
