Should organisations trust third-party access when credentials are already circulating on the dark web?

Why circulating credentials change the trust decision

Once a supplier’s credentials are circulating on the dark web, the question is no longer whether access was ever legitimate, but whether that access can still be trusted. Credential circulation weakens the assurance behind any existing session, token, API key, or federation path, because possession of the credential is enough to impersonate the supplier until the relationship is revalidated.

That is why third-party access should be treated as provisional, not trusted by default, until the supplier’s identity footprint, authentication path, and access scope are checked against current reality. In practice, the security boundary has shifted from “the supplier is known” to “the supplier can still prove control of the identities and secrets that grant access.”

Where the access model depends on reusable secrets, long-lived tokens, or stale entitlements, the chance of misuse is materially higher. NHIMG’s Guide to the Secret Sprawl Challenge explains why exposed credentials often signal a broader control problem, not a single leaked value.

What to verify before you keep third-party access open

Verification should start with the specific identity path that the supplier uses to reach your environment. Confirm which accounts, certificates, OAuth grants, service principals, or API keys are in scope, then check whether the supplier still controls them and whether they are limited to the minimum systems and functions needed for the work.

That review should also cover whether the credential is shared, duplicated, or reused across environments. Reuse turns one exposure into many, and a leaked credential that still works in production can create a much larger blast radius than the original supplier relationship suggests. NHIMG’s Third-Party, B2B and Contractor Access Guide is the clearest starting point for governing sponsorship, least privilege, and time-bounded supplier access.

If the supplier cannot quickly prove control over the relevant identity path, assume the trust signal is stale. NHIMG’s IAM and IGA Basics is useful here because it frames the distinction between authenticating a party and authorizing what that party is still allowed to do.

How to contain the exposure when patching or replacement is not immediate

When you cannot replace the access path at once, the safest interim move is to shrink it. That usually means revoking the most sensitive permissions first, forcing reauthentication, shortening session lifetime, disabling dormant integrations, and putting the supplier behind tighter approval or monitoring until the identity risk is resolved.

Do not keep broad access in place while waiting for the supplier to “confirm nothing was used.” A leaked credential is already a trust problem, and a quiet period does not prove safety. If the access is truly necessary for operations, keep only the minimum route open and make it observable, time-bound, and revocable.

For credential types that are difficult to rotate safely, NHIMG’s Guide to NHI Rotation Challenges helps explain why rotation planning has to account for dependencies, not just the secret itself.

When third-party access is implemented with tokens or federated grants, the same discipline applies to issuance, refresh, revocation, and scope reduction. NHIMG’s API Key Management Guide is a practical reference for leak response, scoping, and revocation logic.

Risk and Threat Considerations

Circulating credentials are a strong indicator that the supplier’s access may already be usable by someone else. The threat is not only direct misuse of the exposed secret, but also impersonation through the same trust path the supplier uses legitimately, which can bypass normal scrutiny and blend into routine partner activity.

Failure mechanism: The attacker or unauthorized party uses the leaked credential, token, or session to authenticate as the supplier, then inherits whatever rights that identity still holds, including access to data, admin functions, or downstream systems connected through federation or trust relationships.

Impact: Exposure can extend well beyond one account, because third-party access often connects to shared data stores, integrations, and privileged workflows. If the supplier’s identity footprint is not revalidated quickly, the organisation may continue trusting an access path that has already been copied, replayed, or abused.

Practitioner Guidance

What to prioritise: Start with the supplier identities that can reach production, customer data, or administrative interfaces. If a leaked credential can still open one of those paths, treat rotation and scope reduction as higher priority than a retrospective hunt for proof of abuse.

What to verify: Confirm the exact authentication mechanism in use, the current entitlements behind it, and whether the supplier can still prove control of the secret or account. If you cannot validate ownership quickly, the access should be considered unsafe until reissued or constrained.

Decision rule: If the third-party credential has any chance of still being valid, assume it is already part of the attacker’s option set and reduce exposure first, investigate second. The right sequence is containment, revalidation, then root-cause analysis.

Practitioner takeaway: The key judgement is that trust must follow live verification, not historical approval, because a circulating credential turns third-party access from a relationship issue into an active identity-risk decision.

Related resources from NHI Mgmt Group

• When should organisations revoke third-party access credentials?
• When should organisations prioritise a third-party secrets manager over storing credentials in the access platform?
• How should healthcare organisations secure third-party access without relying on shared VPN and directory credentials?
• How should organisations implement least privilege and zero trust for critical systems and third-party access?