Assumed Breach: Why modern cybersecurity must be built to withstand attack

For years, cybersecurity was treated as a layer added after systems were built. A firewall here, an endpoint agent there, compliance documented afterwards. That model has quietly collapsed.

Today’s reality is different. Attackers move in minutes, not days. Infrastructure is distributed across cloud, on-premises and operational technology. Users and devices connect from everywhere. In this environment, the old question – “how do we keep attackers out?” – is no longer the right one.

The right question is: when an attacker gets in, how much damage can they actually do?

This is the core of the Assumed Breach mindset. It does not mean giving up on prevention. It means designing systems, processes and response plans around the expectation that prevention will sometimes fail – and ensuring that when it does, the impact stays contained.

Assumed Breach is no longer a niche philosophy for mature security teams. It is becoming the default posture for any organisation that takes digital risk seriously, and it is quietly reshaping how Secure by Design is practised across the Nordics.

Why the old security model no longer works

Traditional perimeter-based security was built on a simple idea: inside the network is trusted, outside is not. That assumption broke a long time ago, but many organisations still operate as if it holds.

Three shifts have made the old model untenable:

1. The perimeter has dissolved. Remote work, SaaS, multi-cloud and OT connectivity mean there is no longer a clear “inside” to defend.
2. Attackers are faster and more automated. Vulnerability-to-exploitation timelines have collapsed from weeks to hours, increasingly aided by AI-driven reconnaissance and automated tooling.
3. Consequences are higher. Ransomware, regulatory fines under NIS2, and operational downtime in critical sectors like power and healthcare have made even short breaches genuinely expensive.

In this reality, the assumption that a strong perimeter is enough is not just outdated – it is a liability.

Zero Trust: The foundation of an Assumed Breach architecture

At the core of Assumed Breach is Zero Trust. The principle is straightforward: no user, device or system is trusted by default. Every access request is verified, every time.

“It’s not about trusting that a user has logged in correctly,” says Henrik Lund, Team Lead Fortinet at NetNordic. “It’s about continuously verifying that it’s the right user, on the right device, accessing the right resources.”

In practice, that means confirming:

• Who the user is (strong authentication, not just a password)
• What device they are using (is it managed, patched, healthy?)
• Why they need access (is this request appropriate for their role, this time of day, this resource?)

Even valid credentials on a compromised device should not grant access. And access, when granted, should be limited to exactly what the user needs for the task at hand – nothing more. This is least privilege access, and it is one of the highest-leverage changes an organisation can make.

Containing the blast: what Assumed Breach looks like in practice

If you accept that a breach will eventually happen, the design question changes. It is no longer “how do we stop every attack?” but “how do we ensure that when one gets through, it cannot spread?”

This reframing has practical consequences:

• A compromised laptop should not grant access to production servers
• A phished admin account should not expose the entire identity directory
• A vulnerability in one SaaS integration should not cascade across business systems

Containment is an architectural property. It is built in through network segmentation, identity boundaries, privilege separation and explicit trust relationships between components. When these boundaries are strong, a breach becomes a contained incident rather than a crisis.

Micro segmentation: from broad zones to controlled access

Many Nordic organisations still rely on traditional network segmentation – dividing systems into a handful of large zones (production, office, guest, OT). It is simple to manage, but once an attacker is inside any zone, lateral movement is often trivial.

Microsegmentation takes a fundamentally different approach. Instead of a few large zones, access is controlled at a much finer level – often down to the individual workload, application or service. Every interaction requires verification. Every system is isolated to the extent possible.

The logic is simple: less access means less risk.

But microsegmentation comes with a trade-off. It is more complex to implement, requires solid visibility into application dependencies, and demands expertise to avoid breaking legitimate workflows. Done poorly, it frustrates users and drives shadow IT. Done well, it dramatically reduces the blast radius of any single compromise.

This is one of the areas where design expertise and experience genuinely matter – and where a wrong turn early on costs years to undo.

Automated patching and the window of exposure

Even with strong access control, vulnerabilities remain. Software is written by humans, and humans make mistakes. Vendors release patches, but applying them is rarely instant.

That delay creates what attackers look for: a window of exposure – the time between a vulnerability becoming known and your systems being protected. With automated scanning and exploitation tools, that window is often measured in hours.

Closing it requires two things:

1. Automated patching, so updates are applied as quickly as operations allow
2. Architecture that supports patching without downtime – redundancy, rolling updates, canary deployments

Automation alone is not enough. It has to be designed in. Once again, the answer comes back to how systems are built in the first place.

Virtual patching for OT and legacy systems in critical infrastructure

Not all systems can be patched. Operational technology in power plants, water treatment, manufacturing and transport often runs on platforms that are decades old, certified for specific conditions, or too critical to take offline for an update. Legacy applications in healthcare, finance and public administration face similar constraints.

For the Nordic power sector in particular, this is not a theoretical problem. IT/OT convergence is real: SCADA and control systems that were once air-gapped are now integrated with corporate networks, cloud monitoring and remote operations centres. The attack surface has expanded faster than the ability to modernise the underlying technology.

This is where virtual patching becomes essential. Rather than modifying the vulnerable system itself, protective controls are placed around it:

• Network traffic is inspected and filtered
• Known exploit patterns are blocked before they reach the system
• Suspicious behaviour triggers alerts and containment

It is not a replacement for patching where patching is possible. But for critical systems that cannot be changed, it keeps the window closed until modernisation is feasible – often over a multi-year horizon.

For operators of critical infrastructure, this approach is no longer optional. It is the foundation of a defensible posture under NIS2 and sector-specific regulation.

Assumed Breach and NIS2: compliance by design

NIS2 and its national implementations (including digitalsikkerhetsloven in Norway) are adding formal weight to what security teams have said for years: resilience must be built in, not retrofitted.

Trying to bolt compliance onto an existing architecture is expensive, slow, and usually incomplete. The organisations that navigate NIS2 successfully are the ones that treat it as an architectural requirement from the start:

• Risk assessment informs design decisions, not just documentation
• Logging, monitoring and incident reporting are engineered in, not added later
• Supplier and third-party risk is part of the architecture, not a separate exercise

When done correctly, compliance becomes an outcome of good design rather than a parallel project. And – critically for boards and executives – it becomes defensible under scrutiny.

Incident response: rehearsing for the inevitable

Even the best-designed systems will experience incidents. Assumed Breach assumes this and prepares for it.

That preparation is more than a documented plan sitting in a SharePoint folder. Mature organisations now run regular simulations – tabletop exercises, red team engagements, full-scale “war games” – where incident response is tested under realistic pressure.

The reason is simple: when a real incident happens, there is no time to learn. Roles must be clear. Decisions must be pre-authorised. Escalation paths must be understood. The first hour of a serious incident sets the trajectory for the next three months.

Across Zero Trust, automation, segmentation, compliance and response, one pattern repeats: security that is designed in holds up. Security that is added on does not.

From principles to practice: how NetNordic helps

Assumed Breach is a mindset, but translating it into architecture, operations and governance is where most organisations struggle. This is where having the right partner matters.

NetNordic works with Nordic organisations across power, public sector, finance and enterprise to translate these principles into practical, resilient architectures. That includes:

• Cyber Advisory – strategy, architecture reviews, NIS2 readiness and Zero Trust roadmaps
• Offensive Security – penetration testing, Red Team and Assumed Breach exercises to validate defences against real attacker behaviour
• Managed SOC – 24/7 detection and response, built on the assumption that something will eventually get through
• Secure infrastructure and network services – designed with segmentation, automation and resilience as defaults

The goal is not perfect prevention. It is designed resilience: systems that contain threats, operations that respond effectively, and a business that keeps running.

Frequently asked questions

What is the Assumed Breach mindset? Assumed Breach is a cybersecurity approach built on the expectation that prevention will sometimes fail. Instead of relying solely on keeping attackers out, it focuses on designing systems, processes and response capabilities that contain the impact when a breach occurs.

How is Assumed Breach different from Zero Trust? Zero Trust is the architectural principle – never trust, always verify. Assumed Breach is the broader operational mindset that Zero Trust is often part of. Zero Trust answers how you design access; Assumed Breach answers why – because you are designing for the moment something gets through.

Is Assumed Breach relevant for small and mid-sized organisations? Yes. In fact, smaller organisations often benefit more, because they have less capacity to absorb a major incident. The principles – least privilege, segmentation, tested response – scale down as well as they scale up.

How does Assumed Breach align with NIS2? NIS2 explicitly requires risk management, incident response and supply chain security. An Assumed Breach architecture addresses these requirements by design, rather than as a separate compliance exercise.

Where should an organisation start? Most organisations get the highest leverage from three things: a current-state assessment of identity and access, a review of network segmentation (especially between IT and OT), and a tested incident response plan. These three alone close the majority of the gap.

Ready for what comes next?

If you are building your organisation’s defences for the realities of 2026 and beyond, the starting point is understanding where you stand today.