Trust relationship persistence is the condition where third-party access continues to work after the business need has changed or ended. In practice, it creates dormant but still valid credentials that can be abused later. The risk is highest when offboarding is manual, ownership is unclear, or revocation depends on another organisation’s process.
Expanded Definition
Trust relationship persistence describes a state in which an external party, application, or integration still has working access after the business justification for that access has changed or ended. In NHI security, the trust is usually embodied in secrets, certificates, OAuth grants, federated assertions, API tokens, or service account links that remain accepted by the target system.
Definitions vary across vendors, but the security meaning is consistent: an authorised trust path outlives the operational need that created it. That makes this term different from simple credential theft, because the access may still be legitimate from the system’s perspective even when it is no longer legitimate from the business’s perspective. It also differs from ordinary overprovisioning, since the problem is persistence across organisational change, not just excess scope at issuance. The lifecycle issue aligns closely with guidance in the NIST Cybersecurity Framework 2.0 and the broader NHI lifecycle emphasis in NHI Mgmt Group’s Ultimate Guide to NHIs.
The most common misapplication is treating trust as permanent infrastructure instead of a revocable business relationship, which occurs when ownership and expiry are not tied to the integration lifecycle.
Examples and Use Cases
Implementing trust revocation rigorously often introduces coordination overhead, requiring organisations to weigh integration continuity against the operational cost of frequent revalidation and deprovisioning.
- A supplier API key remains valid after a contract ends because no one owns the revocation step in the receiving system.
- A federated service connection continues to trust signed assertions from a partner tenant even after the partner’s role in the workflow changes.
- An internal automation account keeps working after a team migrates platforms, leaving dormant access to production resources.
- A certificate-based integration still authenticates successfully after the vendor relationship is paused, because expiry is long and renewal is automatic.
- After lessons from the Salt Typhoon US telecoms breach, many teams reassess how long third-party trust should survive beyond the business need. For implementation guidance, NIST Cybersecurity Framework 2.0 is often used to structure governance and recovery expectations.
In practice, trust relationship persistence is most visible during vendor offboarding, environment migrations, merger integration, and emergency response when inherited credentials are discovered long after they should have been retired.
Why It Matters in NHI Security
Trust relationship persistence turns a normal third-party integration into a hidden attack path. If the relationship is not continuously reviewed, attackers can abuse still-valid access without needing to break authentication, which is why the issue is especially serious for service accounts, API keys, and federated machine-to-machine trust.
NHI Mgmt Group reports that only 20% of organisations have formal processes for offboarding and revoking API keys, and 91.6% of secrets remain valid five days after notification, showing how slowly trust is often removed in real environments. That gap matters because persistent access often survives long after the business owner assumes it is gone, creating a mismatch between policy intent and technical reality. The same pattern is discussed in NHI Mgmt Group’s Ultimate Guide to NHIs, where lifecycle control is presented as a core governance requirement.
Practitioners should treat this as a zero trust and resilience issue, not just an identity hygiene issue. Organisations typically encounter the consequence only after a partner relationship ends, a compromise is investigated, or a post-incident review finds that unused access still worked, at which point trust relationship persistence 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 | Addresses secret lifecycle and revocation gaps that let third-party trust persist. |
| NIST CSF 2.0 | PR.AA | Identity and access governance covers removal of stale third-party access. |
| NIST Zero Trust (SP 800-207) | SP 2 | Zero trust assumes every trust relationship must be continuously validated. |
Tie offboarding to access removal and verify revocation in post-change reviews.
