Why zero trust is becoming engineering's new default

Somewhere right now, a security team is staring at a dashboard, watching the clock on a breach they have not fully contained yet. According to IBM's 2026 Cost of a Data Breach Report, the average incident now takes 247 days to identify and contain, and costs organizations a record 4.99 million dollars globally, up 12 percent from the year before. In the United States alone, that number climbs past 11 million dollars per breach.

Here is the uncomfortable part for engineering teams, a huge share of that cost traces back to architecture decisions made years before anyone noticed a problem, flat internal networks, implicit trust between services, and credentials that could roam far wider than they should have. Zero trust exists to fix exactly that pattern, and in 2026 it is no longer optional homework left for the security team to finish later. It is becoming a baseline engineering requirement, backed by regulation on both sides of the Atlantic.

What zero trust actually means

Zero trust gets thrown around loosely enough that it is worth grounding in its actual definition. The National Institute of Standards and Technology laid out the reference architecture in Special Publication 800-207, describing zero trust as an approach that focuses on protecting resources rather than network segments, since location on a network is no longer treated as a signal of trust.

Three ideas anchor the whole framework. Verify explicitly, meaning every access request gets authenticated and authorized based on all available signals rather than assumed trust from network position. Enforce least privilege, so an identity gets only the access it needs for a specific task, nothing more. And assume breach, designing systems so that a single compromised credential or service cannot move freely across the rest of the environment. None of this is new in concept, but building it into how systems get designed from day one is the shift happening right now.

Why this is now an engineering problem

For years, zero trust lived mostly in security team roadmaps, bolted onto existing systems through network segmentation projects and additional monitoring tools. That approach is running out of road. Modern applications are built from dozens of interconnected services, third-party APIs, and non-human identity and access management challenges like service accounts and AI agents, none of which fit neatly into a model where security gets added after the architecture is already decided.

The practical result is that verifying identity, enforcing least privilege, and designing for breach containment now have to happen at the same table as decisions about databases, APIs, and deployment pipelines. A security team cannot retrofit zero trust onto a system that was never designed to support it, at least not without enormous cost and disruption later.

The regulatory pressure making this non-optional

United States federal requirements

In the US, zero trust adoption has been government policy for years, not just a recommendation. Executive Order 14028 directed federal agencies to adopt zero trust principles, and the Office of Management and Budget followed with Memorandum M-22-09, setting concrete deadlines for agencies to meet zero trust goals. The Cybersecurity and Infrastructure Security Agency built on this with its Secure by Design pledge, which explicitly names threat modeling as one of its core goals, pushing software manufacturers to identify and address security risks during the design phase rather than after release. More than 250 companies, including major cloud and security vendors, have signed on.

European Union rules with teeth

Europe has taken a more regulatory route, and the deadlines are landing right now. The NIS2 Directive sets cybersecurity risk management and incident reporting requirements across 18 critical sectors, with personal liability for management if organizations fail to comply. Layered on top of that, the Cyber Resilience Act introduces the first EU-wide mandatory cybersecurity requirements for products with digital elements, covering everything from industrial control systems to consumer software. Its reporting obligations for actively exploited vulnerabilities became enforceable on September 11, 2026, just days before this article went live, with the full set of obligations phasing in by December 2027.

Australia is moving in a similar direction, with the Australian Signals Directorate's Cyber Security Centre partnering directly with CISA on joint secure by design guidance for manufacturers and procuring organizations, reinforcing that this is not a purely North American or European conversation anymore.

Automated threat modeling turns security into a build step

If zero trust is the destination, automated threat modeling is increasingly how engineering teams get there without grinding development to a halt. Traditional threat modeling meant long workshop sessions with a whiteboard, run occasionally and quickly out of date the moment the architecture changed. That does not survive contact with a team shipping code every few days.

The fix taking hold across DevSecOps teams is treating threat modeling as code, encoding frameworks like Microsoft's STRIDE methodology directly into automated checks that run inside CI/CD pipelines alongside regular tests. Combined with shift-left security practices that push vulnerability scanning and access reviews as early into the development process as possible, this turns threat modeling from a periodic event into a continuous, versioned part of the codebase itself, updated automatically as the system evolves rather than revisited once a year in a meeting room.

What this looks like inside a modern engineering org

In practice, teams adopting this approach lean on a handful of concrete building blocks. NIST's Secure Software Development Framework gives organizations a common vocabulary for practices like generating a software bill of materials for every release and tracking software supply chain security risk across third-party dependencies, both now explicitly expected under frameworks like NIS2 and the CRA.

On the identity side, workload identity is getting the same zero trust treatment historically reserved for human users. Standards like SPIFFE and SPIRE issue cryptographic identities to individual services and workloads rather than relying on static credentials, and all three major cloud providers now support workload identity federation natively, letting a service in one cloud authenticate to a resource in another without a shared secret sitting in a configuration file somewhere.

The cost of getting this wrong keeps climbing

None of this is theoretical risk management for its own sake. IBM's 2026 Cost of a Data Breach Report found that AI-driven attacks increased 56 percent year over year, adding roughly 1 million dollars to the average cost of a breach compared to attacks without AI involvement, and phishing remained the most common way attackers get an initial foothold for a fourth consecutive year. Ransomware, valid account abuse, and supply chain compromises rounded out the leading causes.

That last category is worth sitting with for a moment. A supply chain compromise means the attacker did not even need to break into your systems directly, they got in through a vendor, a dependency, or a piece of infrastructure tooling that was implicitly trusted. That is precisely the blind spot zero trust architecture is built to close.

Where the friction still is

None of this rolls out cleanly, and it is worth being honest about that. Retrofitting zero trust principles onto decades-old legacy systems is genuinely expensive, and plenty of critical infrastructure was never designed with per-request authentication in mind. Smaller organizations, in particular, face a real skills gap, threat modeling as code and workload identity federation both require expertise that is still concentrated in larger, better-resourced teams.

There is also a growing regulatory patchwork to navigate. NIS2, the Cyber Resilience Act, US federal mandates, and emerging Australian guidance do not all define compliance the same way, and the EU itself is currently working through amendments intended to simplify overlapping obligations for smaller companies. Engineering leaders operating across regions will need to track more than one moving regulatory target for the foreseeable future, rather than treating any single framework as a finish line.

The bottom line

Zero trust by design is not a rebrand of existing security practice, it is a genuine shift in who owns the problem and when the work happens. Verification, least privilege, and threat modeling are moving out of after-the-fact security reviews and into the same pull requests, architecture diagrams, and CI/CD pipelines that define how software gets built in the first place. With regulatory deadlines now active on both sides of the Atlantic and breach costs still climbing, treating zero trust as an engineering default rather than a security afterthought looks less like best practice and more like the only practical option left.