Ransomware doesn't stop at your network perimeter

A ransomware incident is not a perimeter incident. It is a chain incident. The encryption you eventually see is the final act in a sequence of steps that began somewhere else: with a supplier that had access, with an identity that was not validated rigorously, with a backup that existed but was not immutable, or with a recovery procedure that was written down but never carried out under pressure. Anyone who fights ransomware by reinforcing the outer edge of the network is defending the wrong part. The perimeter was passed long before the first encrypted files appear. The question on the table, then, is not how high your perimeter is, but how well the chain behind it holds once someone is through.

This piece explains why the framing "we have a strong perimeter" is outdated, which five layers together do form a defence, and how you, as a CISO, take the honest measurement: not whether you can prevent a ransomware attack, but whether you can contain it, recover from it and endure it without the organisation standing still for weeks.

Why is the perimeter framing outdated?

The assumption behind the perimeter framing is that an attacker stands outside and tries to get in, and that the skill lies in building the wall high enough. That picture has not matched reality for a decade. Attackers get in through routes that are not seen as "outside": through a supplier with a permanent VPN connection, through a stolen identity that is valid in your directory, through the browser session of a user who clicked a legitimate link, or through a managed system of a service provider that has itself been compromised. ENISA notes repeatedly in its Threat Landscape that supply-chain and identity abuse are the dominant initial-access paths in ransomware operations, and the Dutch National Cyber Security Centre stresses in its guidance that network segmentation and strict identity control inside the network are baseline measures precisely because the outer edge is no longer the relevant boundary.

What this means in practice is more concrete than the framing suggests. A ransomware actor who enters through a compromised managed service provider is not standing "at the edge of your network". They are inside a trusted zone, with valid credentials, with legitimate administrative paths, and with the time to look around. A perimeter firewall does not see them, because they do nothing the firewall is meant to block. An attacker who lands a phishing link with a user who holds administrative rights does the same. The breach has already happened before a single classic alarm goes off. What stops them or lets them through is not the outer edge, but what stands on the inside: how many paths are open from the system where they landed, whether their identity is re-validated at every sensitive action, whether your backups sit beyond their reach, and whether your organisation can keep running for a week without those backups if it does go wrong.

Which layers together do form a defence?

A ransomware defence is not a wall and not a product. It is a chain of five layers that each intercept a different part of the incident. Weakness in one layer cancels out the gains from the other four, and that is exactly why organisations that invest heavily in a single layer still go under. The five layers, in the order in which they intervene in the attack chain:

Segmentation. The network is divided internally into zones that do not talk freely to one another. A compromised workstation cannot simply reach a file server, a file server cannot simply reach the backup environment, and the backup environment has no path back to production. The MITRE ATT&CK framework describes under Impact tactics (TA0040) how ransomware actors move east-west systematically before they encrypt; segmentation shrinks that room to manoeuvre. This is not a vendor choice, it is a design choice.

Identity validation inside the network. An identity that is valid at the front door is not automatically valid for every subsequent action. Administrative accounts are managed separately, sensitive actions require repeated authentication, service accounts hold minimal rights and are monitored for anomalous behaviour. A stolen password or a hijacked session then does not automatically grant domain rights.

Immutable backups. Backups that an attacker cannot encrypt, cannot delete and cannot expire prematurely. In practice that means: backups that sit in a separate management domain, with independent credentials, with a retention that cannot be lowered without authorised intervention, and with an offline or write-once copy of the most critical datasets. NIST SP 800-184, the Guide for Cybersecurity Event Recovery, states explicitly that the integrity of backups is the determining factor for recovery; a backup that sat within the attacker's reach is not a backup.

Tested recovery. The difference between a recovery plan and recovery is a rehearsal. How long does it take to restore the ten most critical systems from backup, in what order, with what dependencies, and who does what. That answer is only credible if it has been established in a rehearsed setting, not if it sits in a document. The difference between a 24-hour recovery and a two-week one rarely lies in technology; it lies in whether the procedure has ever been run through in full under time pressure.

A grip on the supply chain. Which parties have access to your environment, with what rights, through what connection, and what happens if one of them is compromised. A ransomware actor who enters through a service provider with domain-admin rights bypasses the first two layers entirely. Third-party access should therefore receive the same validation and segmentation as internal access, and in many organisations that is precisely the part that has not been arranged.

These five layers only work together. Segmentation without identity validation is a fence with a gate left open for anyone holding a valid key. Immutable backups without tested recovery are an insurance policy you cannot cash in. Tested recovery without a grip on suppliers is a recovery procedure that starts over the moment the party you let in is also involved in the second round.

What is the honest measure of your resilience?

In many organisations ransomware resilience is measured as the absence of incidents. That is not a measure, that is luck. The right measure is made up of four questions you can answer concretely at each layer. One, how many paths run from any given workstation to the backup environment, measured in network hops and in valid rights. Two, how long it takes for a stolen identity to be recognised and stopped before it reaches a sensitive system, measured from the moment the unusual behaviour occurs. Three, how much time sits between the decision to restore from backup and the moment the ten most critical systems are running again, measured in a rehearsed setting and not in a document. Four, which suppliers hold access that would break through your defence in a ransomware scenario, and what conditions apply to that access.

These four measures together tell you something that the sum of individual controls does not: whether the chain holds as a whole. CISA describes the same approach in its Stop Ransomware material: resilience is not a sum of products, it is a continuous test of the coherence between prevention, detection, containment and recovery. Anyone who does not have these four measures to hand does not know how far along they are, regardless of how much sits in the security budget.

What is a ransomware incident, really?

It is useful to sharpen the definition here, because the framing in much decision-making is still that ransomware is "a virus that encrypts files". That is what you see at the end. A ransomware incident is a multi-step operation in which an attacker gains initial access (often through identity abuse or a supply chain), moves laterally, builds persistence, exfiltrates data for double extortion, deletes or encrypts backups, and as the final step encrypts production data. Against that definition, "we have a strong perimeter" is not a defence but an assumption about one component of step one. The other steps take place inside your own environment, and the defence against those steps lies in the five layers above, not in the outer edge.

This framing also changes where money removes the most risk. An additional investment in perimeter controls on top of an already mature perimeter yields less than a first serious investment in tested recovery or in a grip on third-party access. Not because the perimeter is unimportant, but because the marginal gain of the sixth layer in that spot is lower than the first layer in a spot where nothing yet stands.

What this means for the choice you make

For the CISO who opens the internal conversation with this, the usable summary is that ransomware is not an attack you stop at the edge of your network, but a chain you dismantle further along in five layers. To operational teams, the message is that segmentation, identity validation, backup integrity, tested recovery and third-party access must be chained together in one coherent design, not run as separate projects with their own owners. To the board or the CFO, the message is more businesslike: the measure that counts is how long the organisation stands still when it goes wrong, and that time hangs on five investments at once, not on one.

The logical next step is not a purchase and not an architecture document. It is an honest assessment of where you stand on those five layers, and which layer is the weakest link in your specific chain. That link determines the impact, regardless of how strong the other four are. Set your own situation against those five layers: if one of them is not clear, or if one of them exists only on paper, then that is the conversation you need to have first, internally and, where useful, with someone who looks at it independently.