What breaks when supplier access is reviewed only once a year?

Operational drift breaks the model. Credentials age, certificates expire, subcontractors change, and new internet-facing services appear after the review. By the time the next audit happens, the supplier’s access footprint may be materially different from the one on file, which leaves the organisation governing a stale picture of risk.

Why This Matters for Security Teams

A once-a-year supplier review creates a control gap between governance and reality. Third-party access is not static: service accounts are rotated, certificates expire, integrations are added, and subcontractors inherit access that the original approval never contemplated. The result is not just a paperwork issue. It becomes a privilege management problem, a monitoring problem, and often a resilience problem when a supplier still holds access long after the business need has changed. Guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls is clear that access should be managed and reviewed as part of an ongoing control environment, not treated as an annual event.

The practical risk is that stale access tends to survive because it is embedded in operational dependencies. A vendor may still need API access for one workload, while another dormant integration remains reachable because no one removed it after a change request. That creates hidden exposure across cloud consoles, privileged jump hosts, file shares, and machine-to-machine credentials. In practice, many security teams encounter supplier overreach only after an outage, audit finding, or third-party incident has already exposed how far the access had drifted from the approved state.

How It Works in Practice

Effective supplier access governance needs continuous or event-driven verification, not only a calendar-based review. The review process should connect procurement, IAM, PAM, and asset management so the organisation can confirm who the supplier is, what systems they touch, what credentials they use, and whether those credentials still match the approved business purpose. This is especially important for non-human access such as API keys, service accounts, tokens, and certificates, where the identity may outlive the person or contract that created it. The OWASP Non-Human Identity Top 10 is useful here because it highlights how machine identities can be forgotten, over-permissioned, or left unmonitored once they are in production.

• Link each supplier identity to a named business owner and an expiration date.
• Review permissions after contract changes, scope changes, incidents, or staff turnover.
• Use just-in-time access for administrative tasks where possible, rather than standing privilege.
• Inventory all supplier-owned non-human identities, including dormant integrations and test credentials.
• Log and alert on anomalous supplier activity so drift is detected between reviews.

Operationally, the strongest programs treat supplier access as part of an access lifecycle: request, approve, constrain, monitor, attest, and revoke. That means the review should check not only whether the supplier still exists, but whether the specific entitlement still matches the service description, data classification, and threat model. If the supplier is accessing production systems, cloud control planes, or regulated data, the validation standard should be tighter than for low-risk support access. These controls tend to break down when supplier access is spread across multiple business units with no single inventory of accounts, because no one can reconcile the full footprint quickly enough.

Common Variations and Edge Cases

Tighter supplier access review often increases administrative overhead, requiring organisations to balance assurance against operational speed. That tradeoff is unavoidable, but best practice is evolving toward risk-based cadence rather than one-size-fits-all annual attestation. High-impact suppliers, privileged administrators, and machine identities that can deploy code or change infrastructure should be reviewed far more often than low-risk business users. For lower-risk access, event-driven attestation may be sufficient when paired with strong logging and expiry controls.

There is also no universal standard for this yet across every supplier model. A managed service provider, a cloud hosting partner, and a software reseller may each require different evidence, different owners, and different revocation paths. The key is to ensure the review covers entitlements, authentication material, and delegation chains, not just the named supplier company. For identity-heavy environments, that often means aligning supplier governance with PAM, secrets rotation, and certificate management so access cannot silently persist after a contract change or personnel change.

Where the supplier uses automated workflows or embedded integrations, periodic recertification alone is not enough. The organisation should also validate machine identity ownership, rotation hygiene, and dependency mapping. If the review process cannot prove that a service account is still needed, it should be treated as suspect until confirmed. That is especially true for internet-facing APIs, privileged cloud roles, and shared credentials, where stale access can turn into a direct attack path before the next annual review catches up.

Related resources from NHI Mgmt Group

• What breaks when AI agent access is reviewed only after the fact?
• What breaks when autonomous AI is reviewed with normal access certification cycles?
• What breaks when VPN access is granted once at the edge and then trusted across the network?
• What breaks when third-party access is not reviewed continuously?