What should organisations require from third-party crypto service providers?

Require explicit scope, approval authority, logging, and offboarding for any third party that can hold or move assets. That means knowing who controls the workflow, what they can touch, when access ends, and how evidence is preserved. Without that discipline, delegated custody becomes an unbounded trust relationship rather than a governed service.

What organisations should ask third-party crypto providers to prove

Organisations should require a provider to prove not just that it can move assets, but that the movement is bounded, attributable, and reversible in practice. The key question is whether the provider operates under named authority, clear logging, and a defined exit path, or whether it is effectively holding discretionary control with weak oversight.

For third-party crypto services, the contract and the operating model matter as much as the cryptography. If a vendor can sign, custody, transfer, or recover value, then scope, approvals, logging, and offboarding are not administrative extras, they are the controls that determine whether delegated custody remains governable.

Where third-party custody becomes a control problem

The main failure mode is over-broad delegation. A provider that can touch wallets, signing keys, recovery workflows, or transaction approvals without narrow scope creates a trust concentration that is hard to unwind. That is especially true when the provider also controls support channels, emergency actions, or identity bindings that can change who is able to act.

Good requirements should therefore force the provider to define who can initiate, approve, and execute asset movement; which systems and assets are in scope; and what evidence is produced for each action. For teams building a broader third-party access model, NHIMG’s Third-Party, B2B and Contractor Access Guide is a useful baseline for sponsorship, least privilege, and offboarding discipline.

When the provider uses shared credentials, long-lived tokens, or weakly governed integrations, the control problem shifts from pure service delivery to access governance. The issue is not just compromise, it is that the provider may still be able to act long after the business believes the relationship has ended. NHIMG’s IAM and IGA Basics helps frame the governance side of provisioning, reviews, and deprovisioning.

What evidence should be required before trust is granted

Organisations should require evidence that the provider can show traceability for every privileged action, including transaction logs, approval records, and retention of immutable audit evidence where appropriate. The provider should also be able to demonstrate how access is granted, reviewed, and removed, because offboarding without evidence is only a promise, not a control.

For providers that rely on OAuth apps, API keys, certificates, or other identity-bearing material, the evidence should also cover how those materials are rotated, constrained, and revoked. Past incidents show that exposed tokens and shared integrations can become a quiet path into high-value systems, which is why NHIMG’s Salesloft OAuth token breach and GitHub OAuth token breach 2022 are directly relevant examples of why token handling cannot be treated as background plumbing.

Evidence requirements should also distinguish between nominal and effective control. A vendor can say it has approval workflows, but the stronger test is whether approvals are enforced before access, whether logs capture the exact actor and time, and whether deprovisioning actually prevents further use. That is the standard organisations should use when reviewing NHIs, over-privilege, and unmanaged credentials as part of a third-party access model.

How to make the provider relationship governable over time

Requirements should make approval authority explicit, time bound, and tied to a named business owner. Access should end automatically when the contract, use case, or delegated role ends, and the organisation should be able to verify that the provider cannot retain dormant access paths. The most important practical distinction is between temporary operational access and standing delegated authority, because only the former can be governed with confidence.

Practitioners should prioritise three decisions: who owns the relationship, what exact asset or workflow the vendor can touch, and what event triggers removal. If the vendor can hold or move assets, the offboarding process must include key or token rotation, account closure, and proof that downstream authorisations were actually removed. Industry guidance on access governance is increasingly aligned with this discipline, and for third-party credentials the OWASP Non-Human Identity Top 10 is a strong reference point for secret leakage, overprivilege, and offboarding failures.

When the provider also participates in incident response or emergency recovery, organisations should require a separate exception path and additional monitoring. Otherwise, the same relationship that exists to restore service can be used to bypass normal approval controls. NHIMG’s Third-Party, B2B and Contractor Access Guide is useful here because it ties sponsorship and time limits to a practical lifecycle model, not just a policy statement.

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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Non-Human Identity Top 10	NHI-01 — Improper Offboarding	Third-party crypto access must end cleanly when the relationship ends.
	NHI-05 — Overprivileged NHI	Providers that can move assets need tightly scoped authority and least privilege.
Recommendation — Require provable deprovisioning and revoke all provider access on exit. Constrain provider access to the minimum asset and action set.
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	Delegated custody should be limited to only the actions the provider needs.
	AU-2 — Event Logging	Asset-moving actions need traceable records for accountability and review.
	IA-5 — Authenticator Management	Crypto providers often rely on tokens, keys, or certificates that must be rotated and revoked.
Recommendation — Enforce least privilege for every third-party crypto workflow. Log provider actions with enough detail to reconstruct each asset movement. Rotate and revoke provider secrets on a defined schedule and at offboarding.

Practitioner Guidance

What to verify: Confirm that the provider can prove least-privilege scope, named approval authority, complete action logging, and irreversible offboarding for every asset-moving path. If any of those four is only described verbally, treat the control as incomplete.

Decision rule: If the provider can hold, sign, or transfer assets, require contractual and technical evidence of rotation, revocation, and audit retention before go-live. If it only performs a narrow support function, the access model can be lighter, but it still needs explicit expiry and traceability.

What practitioners underestimate: The hardest part is not onboarding the vendor, it is making sure old access disappears when roles change, incidents end, or the relationship is terminated. In this setting, a vendor is only as safe as the organisation’s ability to prove that delegated authority has a clear end state.

Practitioner takeaway: Treat third-party crypto access as governed custody, not just outsourced operations, and do not approve any provider until scope, authority, logs, and offboarding are all enforceable in practice.