Organisations should recertify third-party identity applications whenever access scope, data scope, or ownership changes, and after any partner relationship update that affects trust. The review should confirm the app still needs its current permissions, still has an accountable owner, and still operates within the approved business purpose.
Why This Matters for Security Teams
Third-party identity applications are not static integrations. They accumulate permissions, inherit trust from partner relationships, and often outlive the business purpose that justified them. Recertification is the control that forces a fresh decision on whether the application still needs access, still has an accountable owner, and still fits the current risk profile. NHI Management Group’s Ultimate Guide to NHIs notes that 92% of organisations expose NHIs to third parties, which makes stale trust a common exposure path.
The issue is larger than periodic paperwork. A partner may add a new SaaS dependency, a service account may expand into production data, or an integration may survive after the vendor relationship changes. That is why current guidance aligns recertification to material change events, not just annual calendars. The OWASP Non-Human Identity Top 10 treats overprivileged and poorly governed non-human access as a recurring control failure, especially when ownership is unclear. In practice, many security teams discover third-party access drift only after an audit or incident has already exposed the gap.
How It Works in Practice
The most defensible approach is event-driven recertification with a scheduled backstop. A third-party identity application should be re-reviewed when any of the following changes: access scope, data scope, ownership, authentication method, downstream API targets, contract terms, or the partner’s risk posture. The review should not simply ask whether the app still exists. It should verify whether the current permissions remain necessary, whether the integration still serves the approved business purpose, and whether the owner can still be identified and reached.
Operationally, teams should combine identity inventory, business ownership metadata, and change-management triggers. That means the app record should capture:
- who approved the original access
- what systems and datasets are reachable
- which partner or vendor is responsible for operation
- what expiry or review date applies
- which secrets, tokens, or certificates support the connection
Recertification should also check for dormant access, unused scopes, and inherited permissions that were never separately approved. This is where the control connects to broader NHI governance: third-party integrations often rely on service accounts, API keys, or delegated tokens that need lifecycle discipline. The 52 NHI Breaches Analysis shows how identity misuse and stale access repeatedly appear in compromise paths, while OWASP’s guidance reinforces that visibility and ownership are prerequisites for safe trust decisions. For implementation detail, many teams pair recertification with automated workflow gates, so a failed review suspends access until an accountable approver reauthorises it.
These controls tend to break down when third-party access is embedded in CI/CD pipelines or shared platform accounts because the business owner cannot easily separate one app’s use from another’s operational dependency.
Common Variations and Edge Cases
Tighter recertification often increases operational overhead, so organisations have to balance assurance against integration friction. That tradeoff is real, especially for high-volume partner ecosystems where access changes frequently. Best practice is evolving, but current guidance suggests using risk-based review intervals for stable, low-impact integrations and immediate recertification for any material change to scope, ownership, or trust.
Edge cases matter. A third-party app may have no obvious human owner because it was created by a departed contractor, or the app may be technically unchanged while the vendor’s corporate structure, hosting model, or security posture has changed. In those situations, the safe response is to treat recertification as a re-onboarding event rather than a checkbox review. Where the application touches production, regulated data, or privileged APIs, some organisations also require proof of least privilege and fresh secret rotation before reapproval. The Top 10 NHI Issues and the OWASP Non-Human Identity Top 10 both point to the same practical lesson: stale trust is rarely visible until it is abused.
For vendor ecosystems with many short-lived integrations, a fixed annual review alone is usually too slow, because the risk arrives when the relationship changes, not when the calendar turns.
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 AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Third-party app recertification depends on owning and inventorying non-human access. |
| NIST CSF 2.0 | PR.AA-01 | Recertification verifies identities and access remain appropriate after changes. |
| NIST AI RMF | Change-triggered reviews support governance and accountability for risk decisions. |
Revalidate third-party access whenever scope or trust changes and revoke outdated entitlements promptly.
