When screening and offboarding are treated as isolated tasks, the program loses continuity and risk compounds across the relationship. Teams may approve a vendor once, then fail to revisit risk as scope expands or access changes. They may also miss the final revocation step, leaving lingering exposure after the relationship ends. That gap weakens governance and makes controls look stronger than they are.
Where screening stops and offboarding should begin
Third-party risk management breaks when screening is treated as a one-time gate instead of the start of a lifecycle. A vendor that is acceptable at intake can become higher risk as integrations expand, scopes shift, or access patterns change. That is why screening, monitoring, and exit control need to operate as one continuous governance process, not separate checkboxes.
The lifecycle issue is especially visible in environments that depend on credentials, tokens, API keys, certificates, or privileged connections. Once those access paths exist, the organisation has to keep tracking who can use them, whether the original purpose still holds, and whether the vendor relationship has changed enough to warrant renewed review. The broader lifecycle guidance in the Ultimate Guide to NHIs and the NHI Lifecycle Management Guide both reflect that same continuity problem: access cannot be governed safely if it is only evaluated at the beginning and ignored at the end.
A useful way to frame the break is that ownership becomes unclear. Screening is often owned by procurement, onboarding, or due diligence teams, while offboarding is left to operations, account admins, or individual relationship owners. When those handoffs are not connected, no one owns the full relationship state, and control decisions become stale faster than organisations notice.
What fails when the relationship is not revisited
When screening and offboarding are isolated, the program usually fails in three places: it misses changes in scope, it loses visibility into active access, and it forgets to remove trust at the end. That means a vendor can pass an initial review, gain more access later, and still be treated as “approved” even though the current exposure no longer matches the original decision.
This is why third-party governance needs explicit triggers for reassessment, not just an intake file. Scope changes, new integrations, elevated privileges, and contract renewals should all force a fresh look at the third party’s access and data handling. The same principle appears in the The State of Non-Human Identity Security and The 2025 State of NHIs and Secrets in Cybersecurity findings, where lifecycle gaps, lingering credentials, and excessive privilege show how exposure persists when revocation and review are not tied together.
Offboarding failure is the most visible symptom, but it is not the only one. If the relationship ends while keys, tokens, or shared credentials remain active, the business may still look “secure” on paper while the vendor retains a live path into production systems. In practice, that means screening gave a false sense of safety because it was never paired with a reliable termination control.
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 surface, NIST CSF 2.0 and CIS Controls v8 set the technical controls, and DORA define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Lifecycle and Offboarding | Vendor access still active after relationship changes is a lifecycle and offboarding failure. |
| NHI-02 — Secrets and Credential Management | Lingering keys, tokens, and credentials are the mechanism that keeps third-party exposure alive. | |
| NHI-06 — Third-Party Risk | The question is about third-party governance breaking when onboarding and offboarding are disconnected. | |
| Recommendation — Tie third-party approval to explicit lifecycle review and revocation of all access paths. Inventory and rotate third-party secrets so inactive access is removed on time. Reassess vendor risk whenever scope, access, or contract state changes. | ||
| NIST CSF 2.0 | GV.OC-01 — Organizational Context | Third-party risk decisions must reflect changing business context and relationship scope. |
| PR.AA-03 — Identity Management, Authentication, and Access Control | Ongoing access and revocation are central to controlling third-party exposure. | |
| Recommendation — Update vendor risk decisions when the relationship context changes. Enforce timely removal of third-party access when it is no longer needed. | ||
| CIS Controls v8 | 6.3 — Access Control Management | Offboarding failures are access-control failures when vendor access is not removed. |
| 5.3 — Account Monitoring and Control | Continuous review is needed to detect stale or excessive third-party access. | |
| Recommendation — Revoke third-party access promptly and verify removal across all connected systems. Review third-party accounts regularly and flag access that no longer matches business need. | ||
| DORA | Article 28 — ICT Third-Party Risk Management | The issue is a classic ICT third-party governance failure involving ongoing oversight and exit control. |
| Article 30 — Key Contractual Provisions for ICT Services | Contracts must define termination, access removal, and ongoing risk obligations. | |
| Recommendation — Maintain oversight of third-party arrangements through onboarding, monitoring, and termination. Require contract terms that cover exit, data return, and access withdrawal. | ||
Practitioner Guidance
What to prioritise: Treat third-party risk as a lifecycle control, not a vendor file. The most important control point is the handoff between approval and revocation, because that is where exposure often accumulates unnoticed.
What to verify: Confirm that every approved relationship has an owner, a review trigger for scope or access changes, and a documented revocation path for keys, tokens, accounts, and integrations. If any of those are missing, the program is relying on memory rather than control.
Decision rule: If a vendor can still authenticate, reach data, or influence production after the relationship should have ended, offboarding has failed regardless of how strong the original screening was.
Practitioner takeaway: The test is not whether the vendor was vetted once, but whether the organisation can continuously prove that access, privilege, and trust were reduced when the relationship changed or ended.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
