How should organisations reduce ransomware risk from third-party access?

Why This Matters for Security Teams

Third-party access is often the shortest path from a supplier foothold to internal systems, especially when vendor accounts are granted broad, persistent privileges. That risk is amplified because supplier identities are not just “users”; they are non-human access paths that can be reused, cached, chained, or abused after the original task is complete. NHI Management Group’s Ultimate Guide to NHIs notes that 92% of organisations expose NHIs to third parties, which makes vendor access a supply chain issue as much as an identity issue.

Security teams commonly miss the fact that ransomware operators do not need to compromise every account when one over-permissioned supplier path can unlock backup systems, remote management tools, or file transfer platforms. The right control objective is not vendor convenience; it is to make every external identity narrow, time-bound, and observable. That aligns with the OWASP Non-Human Identity Top 10 and the defensive emphasis in the NIST Cybersecurity Framework 2.0 on access governance and recovery readiness. In practice, many security teams discover risky third-party paths only after a supplier account has already been used to move laterally during a containment event.

How It Works in Practice

Reducing ransomware risk from third-party access starts with inventory, but not a generic list of vendors. Each supplier identity should be mapped to a specific business service, named task, and owning internal control, so the organisation can answer what the account is for, who approved it, and what happens when that task ends. This is where the NHI lifecycle guidance in 52 NHI Breaches Analysis becomes operational: compromised non-human identities are rarely a visibility problem alone, they are usually a privilege and revocation problem as well.

Effective programs typically combine four controls:

• Just-in-time access for external users and service accounts, with automatic expiry after the approved window.
• Session controls that enforce re-authentication, command logging, and kill-switch revocation.
• Least privilege at the resource level, so a supplier can reach only the named application, host, or bucket.
• Continuous review of vendor pathways against backup, admin, and remote execution tools that ransomware crews commonly target.

For implementation detail, identity teams should prefer short-lived credentials and workload-scoped trust over standing passwords, keys, or shared accounts. That is consistent with the direction of the OWASP Non-Human Identity Top 10 and the broader control structure in NIST Cybersecurity Framework 2.0. Practitioners also need to rehearse revocation in production-like conditions, because a control that works only when systems are quiet is not ransomware-ready. These controls tend to break down when vendors depend on shared jump hosts, long-lived API keys, or unowned service accounts because revocation then becomes operationally risky and slow.

Common Variations and Edge Cases

Tighter third-party access control often increases operational overhead, requiring organisations to balance faster containment against vendor support friction and change-management load. That tradeoff is real, especially when suppliers maintain legacy integrations, overnight support windows, or incident-response retainers that rely on uninterrupted access.

There is no universal standard for this yet, but current guidance suggests treating exceptions as temporary and explicitly risk-accepted rather than letting them become permanent standing access. In some environments, suppliers need emergency elevation for restoration work; in others, managed service providers need read access to logs but not to endpoints or backups. The practical safeguard is to separate business continuity access from administrative convenience and to require a documented revocation test before broadening any exception.

Where maturity is low, organisations can start by removing shared vendor credentials, enforcing per-vendor account ownership, and validating that access can be removed without breaking service. NHI Management Group’s Ultimate Guide to NHIs -- Key Challenges and Risks highlights how often secrets remain exposed long after they should have been retired. That is especially relevant for third-party paths because attackers routinely look for the supplier account that nobody expects to rotate. The operational edge case is environments with deeply embedded legacy vendors, where revocation depends on application redesign rather than policy alone.

Related resources from NHI Mgmt Group

• How can organisations reduce third-party access risk in GRC workflows?
• How can organisations reduce risk from third-party OAuth integrations?
• Should organisations treat third-party access as a privileged identity risk?
• How do organisations reduce risk from third-party machine identities?