What breaks when vendor credentials are never recertified?

When vendor credentials are never recertified, access persists beyond the need that justified it. The result is standing privilege, outdated ownership, and stale secrets that remain usable during a later compromise. Recertification is what prevents a temporary integration from becoming a permanent foothold.

Why This Matters for Security Teams

Vendor credentials are often issued for a narrow operational purpose, then quietly outlive the contract, the integration, or the person who originally needed them. When recertification never happens, access review stops being a control and becomes an assumption. That creates standing privilege, stale ownership, and a long-lived secret that can still authenticate after business need has disappeared. NHI Management Group’s research on secret sprawl shows how quickly dormant credentials become part of an attacker’s opportunity set, especially when they are not tied to a current business owner.

This is not just an access hygiene issue. Unrecertified vendor credentials also weaken accountability, because no one can confidently say who approved them, who still depends on them, or who should revoke them. That gap matters in environments where secrets are copied into scripts, CI/CD jobs, tickets, and shared vaults. The OWASP Non-Human Identity Top 10 treats weak lifecycle control as a core failure mode for exactly this reason. In practice, many security teams encounter credential misuse only after a vendor account has already been reused in a later compromise, rather than through intentional recertification.

How It Works in Practice

Recertification is the point where a vendor credential is re-validated against a current business need, current owner, current scope, and current expiry. Without that step, access tends to accumulate across integrations and support workflows until it is no longer obvious why the credential exists at all. The operational fix is not just periodic review in a spreadsheet. Best practice is evolving toward explicit ownership, short TTLs, and revocation triggers that are tied to vendor offboarding, contract changes, environment changes, or inactivity thresholds.

For non-human access, current guidance suggests treating the credential as a workload identity artifact rather than a permanent vendor login. That means tying it to a named system, a named internal sponsor, and a documented use case, then validating those fields on a schedule. NHI Management Group’s Ultimate Guide to NHIs — Static vs Dynamic Secrets and Guide to the Secret Sprawl Challenge both reinforce the same practical point: secrets that are easy to create but hard to retire will spread faster than teams can track them.

• Assign a business owner and a technical owner for every vendor credential.
• Set a recertification cadence based on risk, not convenience.
• Use the review to confirm scope, usage, and expiry, then revoke if any element is unclear.
• Prefer dynamic or ephemeral credentials where the integration supports them.
• Log recertification outcomes so revocation is auditable, not informal.

The NIST SP 800-63 Digital Identity Guidelines are human-identity focused, but the lifecycle principle still applies: proof of identity is not enough unless assurance is periodically re-established. These controls tend to break down in legacy vendor integrations and shared-service accounts because the owner, the usage context, and the revocation path are all ambiguous.

Common Variations and Edge Cases

Tighter recertification often increases operational overhead, requiring organisations to balance stronger access hygiene against vendor uptime and support friction. That tradeoff is real, especially when a credential powers a fragile integration or an external service with limited renewal support. Current guidance suggests that high-risk access should be reviewed more often, while low-risk automation may be handled through shorter token lifetimes rather than manual review alone.

There is no universal standard for this yet, but several edge cases recur. Shared vendor accounts are especially risky because recertification can confirm one valid user while masking several informal users behind the same secret. Service accounts used by third-party tooling need separate handling because the person who requested them is often not the person operating them today. If a vendor relationship ends but the account remains active for fallback access, that should be documented as an exception with an expiry date, not treated as normal.

Threat data from the 2024 Non-Human Identity Security Report shows that organisations still struggle with dynamic ephemeral credentials and consistent access governance, which is exactly why stale vendor access persists. Recertification is also essential where secrets are embedded in code or pipelines, because revoking the account alone may not remove all copies. If a vendor credential is distributed across scripts, ticket notes, and build jobs, the control fails unless the cleanup process reaches every location where the secret was replicated.

Related resources from NHI Mgmt Group

• How do organisations reduce the dwell time of exposed credentials at scale?
• How should organisations stop auto-sync from turning desktops into repositories of credentials?
• What breaks when repository secrets are never recertified?
• What breaks when a privileged account is re-bound after a reset but never recertified?