Who should be accountable when an unapproved application creates exposure?

Why This Matters for Security Teams

When an unapproved application creates exposure, the failure is usually not just “an app problem.” It is a control failure across procurement, inventory, identity, and offboarding. Security teams often discover the issue only after a service account, API key, or unmanaged integration has already expanded access. NHIMG research shows that only 5.7% of organisations have full visibility into their service accounts, which makes accountability difficult to prove and even harder to enforce. The broader pattern is consistent with Ultimate Guide to NHIs — Why NHI Security Matters Now and the breach patterns documented in The 52 NHI breaches Report: exposure rarely stays confined to the original application.

From an accountability standpoint, the business owner owns the risk decision, ITAM owns the asset record, and the identity team owns the access path. That split is necessary because unapproved applications can still consume secrets, inherit permissions, or connect to production systems without proper review. Practitioners should also treat the asset layer and the identity layer as linked obligations, not separate discussions. In practice, many security teams encounter the real blast radius only after the unapproved application has been integrated into workflows, rather than through intentional governance.

How It Works in Practice

The cleanest operational model is to assign accountability at the point of control, then enforce it at the point of exposure. The business owner is accountable for why the application exists and whether the use case is approved. ITAM is accountable for whether the application is recorded, classified, and reviewed in the inventory. The identity team is accountable for whether the application can authenticate, what secrets it uses, and whether access is revoked when the app is no longer authorised. That division maps well to standards such as ISO/IEC 19770 for asset management, while identity controls should align to zero trust and least privilege principles.

Security teams should make this concrete:

• Require every application to have an owner before it can receive credentials or network access.
• Block provisioning of secrets until the application is present in the ITAM record.
• Bind every service account, API key, or certificate to a named business owner and a review cycle.
• Trigger offboarding when the application is retired, unapproved, or abandoned.
• Escalate exceptions through a formal risk acceptance process, not an informal ticket trail.

This becomes especially important for NHI exposure because credentials can outlive the application that created them. NHIMG data shows that 71% of NHIs are not rotated within recommended time frames and only 20% of organisations have formal processes for offboarding and revoking API keys. That is why the accountability model must extend beyond software ownership into access governance. Guidance from Guide to the Secret Sprawl Challenge reinforces the same point: secrets sprawl turns one unapproved app into a persistent exposure problem. These controls tend to break down in fast-moving CI/CD environments because credentials are issued before ownership and inventory checks are completed.

Common Variations and Edge Cases

Tighter accountability often increases operational overhead, requiring organisations to balance speed of delivery against traceability and revocation discipline. There is no universal standard for every case, so current guidance suggests adjusting the control model for shadow IT, third-party apps, and internally built automation differently. A vendor-managed application may still be owned by the business unit that commissioned it, while the vendor may control some technical administration. In a merger, the legacy inventory and identity records may be incomplete, so accountability may need temporary bridge ownership until records are reconciled.

Edge cases also appear when an unapproved application is discovered after it has already issued secrets. In that situation, the immediate priority is containment: revoke credentials, disable access paths, and determine whether any downstream systems inherited trust. If the application touched production data, accountability should include incident response leadership, because the question is no longer just “who approved it” but “who is responsible for stopping continued exposure.” The practical lesson is that accountability must be shared, but it cannot be vague. One owner for approval, one owner for inventory, and one owner for access remains the most workable model. For deeper context, the patterns in 52 NHI Breaches Analysis show how quickly unmanaged access becomes systemic once a single application is missed.

Related resources from NHI Mgmt Group

• Who is accountable when a lost laptop leads to data exposure through delayed revocation?
• Who is accountable if an MSP onboarding workflow creates excessive access?
• Who should be accountable when automated provisioning creates unauthorised access?
• Who is accountable when shadow IT creates access risk?