An application registered inside an organisation's own tenant and therefore treated as internal. In identity governance terms, it is a non-human identity with its own ownership, scopes, secrets, and revocation lifecycle, which means it can become a persistent access path if not reviewed separately from the user account that created it.
Expanded Definition
A second-party application is an application registered in an organisation’s own tenant and treated as internal, but it should still be handled as a distinct non-human identity rather than assumed safe because a user created it. In practice, it carries its own scopes, secrets, consent grants, and revocation path, so it must be governed independently from the human account that deployed it.
Usage in the NHI domain is still evolving across vendors, but the security meaning is consistent: internal registration does not eliminate identity risk. A second-party application may authenticate through client secrets, certificates, or federated assertions, and each mechanism creates a separate lifecycle that must be monitored, rotated, and retired. This is closely aligned with the control expectations in NIST Cybersecurity Framework 2.0, especially where governance, access management, and asset visibility intersect.
The most common misapplication is treating the application as harmless “internal software” and leaving its permissions untouched when the creating user changes roles, leaves the organisation, or no longer needs the integration.
Examples and Use Cases
Implementing second-party application governance rigorously often introduces ownership overhead, requiring organisations to weigh integration speed against review, rotation, and offboarding discipline.
- A finance automation app is registered by an employee in the corporate tenant, then continues calling billing APIs long after that employee moves teams.
- A custom reporting app stores a client secret in a CI/CD variable, which makes the application operationally internal but still exposed as a persistent secret-bearing identity.
- An HR integration uses delegated access to read directory attributes, and access remains active even after the app’s original business purpose changes.
- A security team inventories all internal app registrations and maps them to owners, secrets, scopes, and renewal dates to support offboarding.
- An internal workflow app is reviewed after a merger because the tenant boundary did not prevent privilege creep or stale consent.
These scenarios are easier to assess when paired with NHI lifecycle guidance from Ultimate Guide to NHIs and identity assurance concepts from NIST Cybersecurity Framework 2.0, because the core question is not who created the app but who can still use it, under what scopes, and for how long.
Why It Matters in NHI Security
Second-party applications matter because they often become invisible persistence paths. Once an app is registered inside the tenant, it can outlive the user who created it, keep high-value scopes, and remain active with no one clearly accountable for secret rotation or revocation. NHIMG research shows that only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, which makes internal app registrations a common weak point rather than a minor administrative detail.
That risk is amplified by the broader NHI landscape: the Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, so a seemingly routine internal app can become a broad access path if scopes are not reviewed. Governance should therefore cover ownership, consent scope, secret storage, rotation cadence, logging, and decommissioning, even when the app lives inside a trusted tenant. The operational lesson is reinforced by NIST Cybersecurity Framework 2.0, which expects identity and access controls to be continuously managed, not assumed secure because an asset is internal.
Organisations typically encounter the real impact only after a former employee, compromised account, or forgotten integration is found still holding access, at which point second-party application review becomes operationally unavoidable.
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-01 | Second-party apps are internal NHIs that still need ownership and lifecycle control. |
| NIST CSF 2.0 | PR.AA-01 | Internal applications still require identity assurance and access governance. |
| NIST Zero Trust (SP 800-207) | AC-4 | Zero Trust requires every app identity to be explicitly authorized, even inside the tenant. |
Treat each registered app as a managed identity with reviewed scopes and accountable ownership.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 14, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
