The Ransomware You Signed For

Ransomware readiness starts with knowing which identities and third parties could give an attacker broad access to critical systems.

By testing that access before it’s exploited, organizations can often uncover hidden paths, strengthen detection, and reduce the business disruption and uncertainty an attack can cause.

Here’s where those paths often begin and what leaders and technical teams can do about them.

A ransomware attack rarely starts with ransomware

When leaders picture a ransomware attack, they tend to picture the end of it: locked screens, a ransom note, and a deadline. By the time that note appears, the attack is mostly over. The part that decided the outcome happened days or weeks earlier, quietly, through access that already existed.

In penetration testing work, teams rarely get in by breaking through a firewall anymore. Most organizations have locked that door well.

They get in by using an identity that had more power than anyone realized, or through a third party trusted far more than it was ever tested.

Those same two paths are what ransomware operators look for, because they lead to the outcome they need: control broad enough to reach the systems that matter, all at once.

What ransomware data reveals about third-party risk

Outside data points the same direction. The 2026 Verizon Data Breach Investigations Report found ransomware present in 48% of breaches, and third-party involvement in 48% of breaches, up roughly 60% from the prior year.

The FBI Internet Crime Complaint Center received 3,611 ransomware complaints in 2025 and notes that reported losses understate the true cost, because downtime and recovery aren’t fully captured.

How excessive identity access increases ransomware risk

Giving attackers a path to administrative control

On one internal network assessment, our team started from a limited position, the kind of access a single compromised employee account might provide. Over the course of the engagement, we reached administrative control over the environment.

The specific steps aren’t the point. What matters is what that control represents. Administrative reach across the environment is the exact objective a ransomware operator works toward before encrypting anything.

Allowing identity misuse to go undetected

While our team moved through that environment, nothing raised its hand. No alert. No investigation. No phone call. Had this been a real attacker, the organization’s notice would likely have come from outside the building, in the form of a ransom note.

Extending access beyond multifactor authentication

This is the identity problem in plain terms. Most organizations can tell you which roles exist. Far fewer can tell you what each role can actually reach, or when someone last tested whether those boundaries hold.

Multifactor authentication protects the front door. It does little once a valid identity is already inside and quietly holds more power than intended.

How vendor access creates a ransomware path

In a different example, the organization had done nearly everything right on its own systems. The exposure came through a third-party application the business relied on every day. A weakness inside that embedded product created a path into the environment behind it.

The trust in that product had been established by a signed contract, a completed questionnaire, and a certificate on file. None of those answered the question that mattered: If this product or connection is abused, what can it reach inside our environment? Nobody had asked, so nobody could answer.

For ransomware, that gap is an invitation. Vendor connections, remote support tools, and integrations often run with broad, standing access and limited monitoring. An attacker who compromises the vendor side doesn’t need to defeat your controls. They inherit the trust you already extended.

How data access becomes extortion

Turning a recovery event into a disclosure event

Ransomware crews no longer stop at encryption. They take a copy of sensitive data before encrypting, then threaten to publish it. That turns a recovery problem into an extortion problem, and it means strong backups alone don’t end the incident.

An organization may be able to restore systems and resume operations, but leadership and legal counsel still want an answer to a different question: Was sensitive information exposed?

Creating uncertainty about what attackers accessed

On another engagement, our team found a web application exposing sensitive personal records through an interface that didn’t require anyone to log in.

The records were reachable. No data was taken, and no evidence was found that anyone else had taken it. But no one could demonstrate that no one ever had.

That distinction matters. When access exists and visibility is limited, organizations may struggle to determine whether exposure resulted in actual data loss.

Making evidence as important as restoration

This is the position leaders want to avoid. If a regulator, counsel, or key client asks what was taken, answering “we can’t say” carries a very different cost than answering “this set of files.”

Identity and third-party paths are often where that uncertainty begins, because they are the paths least likely to be logged, reviewed, or tested.

How leaders can reduce ransomware business disruption

• Downtime has a number. Ransomware is a business continuity event. It decides whether you can operate, invoice, or serve clients on a given morning.
• Attestation isn’t verification. Contracts and questionnaires describe what a vendor says. Testing shows what a vendor connection can actually do.
• Evidence decides the conversation afterward. If the organization can’t show what an identity or vendor could reach, it can’t rule out what an attacker reached.

How technical teams can strengthen ransomware readiness

• Map which accounts, service accounts, and vendor connections hold administrative or broad access, and remove standing privilege not needed day to day.
• Treat vendor and integration access as its own attack surface: segment it, log it, and alert on unusual use.
• Validate detection by testing it. Owning an alerting tool isn’t the same as knowing it fires on real attacker behavior, and that a person acts on it.

Three ransomware readiness questions to ask this month

1. Who holds the keys? Which identities, human or service, could reach administrative control of our core systems today, and when did someone last test that?
2. What did we test, not what did we sign? For our top vendors and integrations, what has anyone verified about what that connection can reach inside our environment?
3. Would we notice? If an identity or vendor connection were misused tonight, what alert would fire, and who would respond?

If any of these answers takes more than a few minutes to produce, that’s a useful signal about where ransomware readiness work should start.