Second-Party Application

What Makes a Second-Party Application Different

A second-party application is not just “another internal app.” It is an application object that lives inside your tenant, so the platform treats it as part of your own trust boundary. That means the object itself can hold scopes, secrets, delegated access, and ownership metadata, and those permissions can outlive the user who created it.

This distinction matters because the security question is not whether the app was created internally, but whether the app has been separately governed, reviewed, and revoked on its own lifecycle. In practice, that makes the application object a security principal in its own right.

How Second-Party Applications Fit into Identity Governance

In identity governance, a second-party application behaves like a non-human identity with its own authority surface. It may authenticate with client credentials or certificates, call APIs, access data, or trigger automation without an interactive user session. If that relationship is not explicitly owned, it can become a durable access path that is easy to forget and hard to unwind.

The governance implication is simple: the application should be inventoried, assigned an owner, and reviewed on a schedule separate from the human account that registered it. That review needs to consider what the app can reach, which secrets it depends on, and whether its scopes still match a current business need.

Why the Ownership and Revocation Model Matters

Second-party applications often outlast the business purpose that created them. If the original builder leaves, teams may still keep the app alive because other systems depend on it, which turns a convenience object into a persistent access bridge. The risk is not only unauthorized use, but also blind dependency, where no one is clearly accountable for the app’s continued authority.

Because the app is registered in your own tenant, revocation is under your control, but that also means revocation failure is your failure. If you cannot identify the app, its scopes, its secret material, and the services that depend on it, you cannot safely remove it without causing outages or leaving dormant access behind.

• Separate the application review from the user review so the app is not implicitly trusted just because a known employee created it.
• Treat scopes, secrets, and ownership as first-class governance attributes, not as incidental setup details.
• Review whether the app is still required by a real business process, not just whether it still works.

What Good Operational Control Looks Like

Operationally, a second-party application should be managed as a named asset with a defined owner, purpose, and expiry or review cadence. The practical control objective is to reduce untracked persistence: if the app can still act, it should be because someone has consciously approved that access, not because the registration was never revisited.

That also means monitoring for stale secrets, orphaned ownership, overbroad scopes, and unused app registrations. Where the app supports automation or system-to-system access, use the same discipline you would apply to other privileged non-human identities: least privilege, explicit rotation, and clear offboarding when the function ends.

Risk and Threat Considerations

Second-party applications create a durable trust path that adversaries and internal misuse can both exploit. If the app’s secret is exposed or its permissions are broader than needed, the object can provide quiet, persistent access that is harder to notice than an interactive account compromise.

Failure mechanism: The application outlives its human owner, keeps valid scopes or secrets, and remains trusted by downstream systems even after the original justification has faded.

Impact: Attackers or unintended users can reuse the app as a persistent access path, leading to unauthorized API calls, data exposure, privilege abuse, or difficult-to-detect lateral movement through connected systems.

Practitioner Guidance

Governance implication: Review second-party applications on their own lifecycle, not as an extension of the creating user. The most common failure is assuming that an internal registration is automatically safe, when the real control problem is whether the app still has a legitimate owner, purpose, and scope.

Practitioner takeaway: If an application can act independently, it needs independent governance. The test is not who created it, but who can still justify, monitor, and revoke it today.

Related resources from NHI Mgmt Group

• Who should be accountable for third-party account connections in application workflows?
• Who is accountable when a third-party enterprise application is exploited through a zero-day?
• Why do third-party OAuth grants create more risk than a single application login?
• When does third-party application patching become a governance issue?