The app gap is the difference between the applications an organisation uses and the applications its identity systems can actually govern. It appears when apps do not support standards such as SCIM, SAML, or OIDC, leaving lifecycle actions dependent on custom workarounds or manual execution.
Expanded Definition
The app gap is not just a tooling issue, but a governance gap: it describes the distance between what an identity platform can automate and what a real application will actually accept. In NHI operations, the gap is most visible when lifecycle actions such as provisioning, deprovisioning, rotation, or attribute updates cannot be driven through SCIM, SAML, or OIDC, or when the app exposes only partial APIs. Usage in the industry is still evolving because some teams apply the term narrowly to SaaS onboarding, while others include legacy systems, custom apps, and agent runtimes that cannot be managed through standard identity flows. That distinction matters because the operational response is different: some apps need federation, others need compensating controls, and others must be isolated behind PAM or workflow automation. NIST’s NIST Cybersecurity Framework 2.0 frames this as a control-coverage problem across identity governance and access management. The most common misapplication is treating any app with a login screen as identity-governed, which occurs when administrators confuse authentication with end-to-end lifecycle control.
For broader NHI context, the app gap often becomes more severe as service accounts, APIs, and agents multiply faster than the organisation’s control plane can absorb, as described in Ultimate Guide to NHIs.
Examples and Use Cases
Implementing app governance rigorously often introduces integration overhead, requiring organisations to weigh lifecycle assurance against the cost of custom connectors, manual exception handling, or platform refactoring.
- A legacy finance app supports login through SAML but cannot receive SCIM deprovisioning events, so access removal depends on ticket-based manual action.
- A SaaS tool exposes an API for creating users but not for revoking API keys, leaving secrets management outside the normal joiner-mover-leaver workflow.
- An AI agent uses a vendor platform that supports OIDC for human admins, yet its service token rotation is undocumented, creating a blind spot in control mapping.
- A custom internal app cannot ingest RBAC changes from the identity stack, so access reviews become spreadsheet-driven and inconsistent with the NIST Cybersecurity Framework 2.0.
In practice, teams use the app gap to prioritise remediation: fully standardised apps move to automated governance first, while partial-support apps receive compensating controls such as PAM, time-bound access, or stricter monitoring. The term is especially useful when comparing vendor claims against actual lifecycle coverage. A platform may advertise “identity management,” yet still leave offboarding, rotation, or attestation unresolved for high-risk NHI workflows.
Why It Matters in NHI Security
The app gap matters because every unmanaged application becomes a place where NHI risk accumulates outside policy. If a service account, token, or agent credential cannot be revoked quickly, exposure can persist long after a user or system should have lost access. That is why NHI governance must include application-level coverage checks, not just directory-level controls. In the Ultimate Guide to NHIs, NHI Mgmt Group notes that only 20% of organisations have formal processes for offboarding and revoking API keys, which shows how often lifecycle control breaks down at the application edge. This gap also affects Zero Trust planning, because NIST Cybersecurity Framework 2.0 and related zero trust practices assume that identity and access changes can be enforced consistently across systems. When they cannot, compensating controls must fill the void. Organisations typically encounter the operational cost of the app gap only after a breach, a failed audit, or a delayed offboarding event, at which point the term becomes operationally unavoidable to address.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers secret and lifecycle control gaps created by non-governable apps. |
| NIST CSF 2.0 | PR.AC-1 | Identity governance depends on access control coverage across all applications. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuous enforcement even when apps lack native identity standards. |
Inventory unsupported apps and add compensating controls for provisioning, rotation, and offboarding.
