No. Ratings and access reviews solve different problems. Ratings help prioritise which suppliers deserve attention, while access reviews confirm which identities, credentials, and privileges are actually active. Mature programmes use ratings to triage and access reviews to verify whether third-party access still exists and is appropriately scoped.
Why security ratings and access reviews answer different questions
Security ratings are useful as a prioritisation signal. They give procurement, risk, and security teams a fast way to sort suppliers by apparent exposure, control maturity, or change in posture. Third-party access reviews are a verification control. They answer a narrower but more operationally important question: which external identities, credentials, and privileges are still active, and are they still justified?
That distinction matters because a good rating does not prove that dormant vendor access has been removed, and a poor rating does not prove that every active connection is excessive. Ratings can tell you where to look first; they cannot confirm entitlement scope, offboarding status, or whether a specific supplier account still reaches production systems.
A mature programme treats ratings as triage, then uses IAM and IGA Basics to understand why access review is the control that actually validates who has access, on what basis, and with what privilege level.
What each control should be used for in a third-party programme
Use ratings to focus limited effort. If dozens or hundreds of suppliers exist, ratings help identify which relationships deserve deeper review, tighter onboarding criteria, or faster escalation when a supplier’s posture changes. They are especially useful when the business needs a rough external view before contract renewal, integration expansion, or a new shared workflow goes live.
Use access reviews to confirm the actual state of access. A review should answer whether the third party still needs the account, whether the credential is still valid, whether the access is constrained to the intended environment, and whether the privilege level matches the business need. That is a governance and entitlement question, not a rating question.
For organisations managing contractors, suppliers, and B2B users, the right operating model is usually closer to Third-Party, B2B and Contractor Access Guide than to a scoring dashboard, because the real control points are sponsorship, time limits, least privilege, and offboarding discipline.
Where programmes struggle, it is often because ratings become a proxy for governance. They are not. A supplier can have a strong score and still retain an old API key, a long-lived token, or a stale delegated account. The answer is not to discard ratings, but to place them upstream of review, not in its place.
How mature teams combine ratings, reviews, and evidence
Mature teams build a sequence: score the supplier, verify whether access exists, then decide whether the access should remain. That order avoids two common failures, over-reviewing low-value suppliers while missing high-risk connections, and assuming a good external score means the access estate is clean. If the review process is closed loop, the outcome should be actual removal or reduction of access, not just a documented exception.
Reviews should also cover the lifecycle of non-human access, because a third-party relationship often includes tokens, certificates, service principals, or other machine-facing credentials that outlive the original business purpose. When those credentials persist, they become a separate exposure that the rating alone will not surface. Lifecycle control is why teams should pair vendor triage with credential hygiene and timely retirement of unused access paths.
That is the logic behind the Access Reviews and Certification Guide, which is built around cutting review noise, adding context, and closing the loop so access changes actually happen.
Risk and Threat Considerations
Ratings can create false confidence if they are treated as proof of trust. The main risk is not that a score is wrong in the abstract, but that a security team stops asking whether a supplier still has active access to sensitive systems. That creates a gap between external posture assessment and internal entitlement reality, which is exactly where dormant accounts, stale tokens, and over-privileged integrations persist.
Failure mechanism: A supplier’s score may remain acceptable while its live access paths drift, expand, or survive offboarding. Attackers and insiders benefit from that gap because a forgotten account or token is often easier to abuse than a freshly provisioned, tightly reviewed one.
Impact: Excess access can remain in place long after the business need has changed, increasing the chance of unauthorised data access, lateral movement through third-party integrations, and delayed detection when a vendor relationship is compromised.
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 and OWASP API Security Top 10 address the attack surface, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Third-party access reviews validate whether external accounts still exist and remain justified. |
| IA-5 — Authenticator Management | Ratings do not verify token, key, or secret lifecycle, but access reviews must cover active authenticators. | |
| AC-6 — Least Privilege | The question hinges on whether third-party privileges are appropriately scoped, not just whether a supplier is high or low risk. | |
| Recommendation — Review and remove third-party accounts that no longer have a valid business need. Rotate, revoke, or expire third-party credentials when access is no longer needed. Limit each third-party identity to the minimum privileges required for its approved use. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Third-party access reviews are an access-control verification activity within the ISMS. |
| A.5.18 — Access rights | The page distinguishes supplier ratings from verifying whether access rights still exist and are appropriate. | |
| Recommendation — Define, review, and enforce third-party access rules against approved business need. Recertify and remove third-party access rights that are no longer required. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Third-party access often includes machine credentials whose scope can exceed the business need. |
| NHI-07 — Long-Lived Secrets | Access reviews must catch stale vendor tokens and secrets that ratings will not expose. | |
| NHI-01 — Improper Offboarding | The question is partly about whether old vendor access still exists after the relationship should have ended. | |
| Recommendation — Audit third-party machine credentials for excessive permissions and shrink their blast radius. Expire or rotate long-lived third-party secrets that remain active beyond their intended use. Remove third-party access promptly when a supplier, contractor, or integration is retired. | ||
| OWASP API Security Top 10 | API9 — Improper Inventory Management | Access reviews depend on knowing which external integrations and accounts still exist. |
| Recommendation — Inventory external API consumers and remove orphaned third-party access paths. | ||
| CIS Controls v8 | CIS-5 — Account Management | The answer depends on managing active third-party accounts rather than only scoring suppliers. |
| Recommendation — Maintain an accurate inventory of third-party accounts and disable unused access promptly. | ||
Practitioner Guidance
What to prioritise: Treat ratings as a vendor ranking tool, not a control. Prioritise access reviews for suppliers with active production reach, privileged integrations, long-lived secrets, or access to regulated data.
What to verify: Every review should confirm the identity, credential type, business owner, scope, expiration, and last-use status of the third-party access path. If you cannot prove those fields, the review is not complete enough to rely on.
Common mistake: Teams often review the supplier relationship while ignoring the actual access artifact. That misses the real security question, which is whether a specific identity or credential is still authorised to do anything useful.
Practitioner takeaway: Use ratings to decide where to look, but use access reviews to decide whether access should still exist. If the two disagree, trust the verified access record over the score.
Related resources from NHI Mgmt Group
- How should security teams run access reviews for non-human identities?
- How should security teams govern third-party AI agents that use OAuth access?
- Should organisations use security skill prompts instead of access controls for AI agents?
- How should security teams use a SOC 2 report in third-party risk reviews?