The Mythos Moment: Why AI-Discovered Zero-Days Changed the Math

On April 7, 2026, Anthropic launched Project Glasswing, a $100 million AI cybersecurity initiative built on Claude Mythos Preview, a model Anthropic describes as too dangerous for public release. According to Anthropic's red team assessment, Mythos autonomously discovered thousands of high-severity zero-day vulnerabilities across every major operating system and every major web browser. Among the findings: a 27-year-old OpenBSD TCP SACK bug that survived in one of the most security-hardened operating systems ever built, a 16-year-old FFmpeg vulnerability that automated fuzzing tools hit five million times without catching, and a 17-year-old FreeBSD NFS remote code execution flaw (CVE-2026-4747) that Mythos identified, exploited, and chained into unauthenticated root access, autonomously, for under $50 (Anthropic Project Glasswing). The companion piece walks through what Mythos found and why it changes the threat model for every unpatchable device.

Here is the math that should keep you up at night. Average time-to-exploit after disclosure has collapsed to five days, down from 32 days in 2021–2022 (Mandiant, Google Cloud, 2024). And that five-day figure predates Mythos-class capabilities. Enterprise mean-time-to-remediate ranges from 63 to 104 days depending on sector (Edgescan, 2024 Vulnerability Statistics Report). For OT, IoT, and IoMT devices, patching was never the primary answer. Most deployed devices of these classes carry unpatched CVEs for years, often because patches are not available or cannot be applied within operational constraints (Claroty Team82, Global State of CPS Security 2024). These devices were unpatchable by design. WannaCry infected at least 81 NHS trusts across England through exactly this lateral movement pattern, the same pattern these frameworks were designed to stop (UK National Audit Office, October 2017).

Six compliance frameworks, developed independently, by different bodies, for different industries, arrived at the same conclusion: identity-aware, agentless network segmentation is the mandatory compensating control for devices that cannot be patched. This paper maps microsegmentation requirements across NIST SP 800-207, NIST CSF 2.0, IEC 62443, HIPAA 2025 NPRM, PCI DSS 4.0, and CISA ZTMM v2.0. The remaining question is not whether to microsegment. It is how fast you can deploy.

Why microsegmentation is now a compliance requirement

Every major compliance framework has mandated controls to limit east-west movement for years. NIST SP 800-207 was published in 2020. IEC 62443 has required zones and conduits since 2009. PCI DSS has called for network segmentation across multiple revisions. CISA's Zero Trust Maturity Model, HIPAA's 2025 Security Rule update, and NIST CSF 2.0 are refinements of a control that was already on the books. What held organizations back was never the requirement. It was balancing operational simplicity against the business impact of implementing it. Reshaping a production network around a segmentation policy costs downtime, coordination with device vendors, and risk to clinical, industrial, or revenue-generating systems that the business will not accept on a compliance calendar.

Unpatchable devices made that trade-off uncomfortable. Patching was never the primary answer for OT, IoT, and IoMT assets. Most deployed devices in these classes carry unpatched CVEs for years because the vendor has not released a fix, the maintenance window does not exist, or the warranty prohibits it (Claroty Team82, Global State of CPS Security 2024). These devices were unpatchable by design. Enterprise mean-time-to-remediate where patches do exist still runs 63 to 104 days depending on sector (Edgescan, 2024 Vulnerability Statistics Report). AI-accelerated vulnerability discovery compresses the attacker side of that equation toward a 24-hour ceiling. The compliance requirement did not change. The time you have to satisfy it did.

Nation-state campaigns have spent the last several years demonstrating the exact lateral-movement pattern these frameworks were written to stop. APT29 pivoted through the 2024 TeamViewer intrusion toward downstream targets. Iranian operators exploited exposed PLCs in U.S. water, energy, and government systems. APT28's FrostArmada campaign hijacked over 18,000 routers across 200+ organizations through DNS manipulation. In each case the initial compromise was not the catastrophe. The lateral movement was. WannaCry infected at least 81 NHS trusts across England through exactly this pattern (UK National Audit Office, October 2017). The language varies across frameworks. NIST calls it micro-segmentation. IEC 62443 calls it zones and conduits. HIPAA 2025 calls it network segmentation. CISA calls it a critical component of zero trust. The functional requirement is identical: identity-aware enforcement at the network layer that contains blast radius when a device is compromised.

Organizations have had three realistic architectures available to meet that requirement. Each one is where the business-versus-operational trade-off broke down.

Perimeter firewalls. Next-generation firewalls at north-south boundaries are effective and well understood. The problem is scale. Deploying a firewall in front of every device population that needs east-west isolation is financially and operationally unrealistic for most enterprises. The rack space, cabling, policy-management overhead, and upgrade cycles do not scale to the dozens of device classes a typical hospital, plant, or campus needs to contain. Firewalls ended up deployed at the boundaries auditors could see, not at the boundaries attackers actually crossed.

VLAN segmentation. Separating device classes by Layer 2 broadcast domain works in a stable, greenfield design. Real networks are not greenfield. They grow organically over a decade, and before you know it the IT user VLAN, the IoMT imaging VLAN, and the OT control VLAN share the same switches and the same subnet. The corrective action, re-IPing and re-VLANing devices into purpose-built segments, is operationally impossible for most of the fleet. The business will not authorize the downtime to touch patient-facing clinical systems. The OT vendor who owns the PLC configuration will not schedule a change on the operator's calendar, and in many cases contractually controls the asset. VLAN segmentation is fine for coarse separation. It is not a mechanism you can use to enforce policy across a live, mixed-criticality production network.

Host-based agents. Microsegmentation agents on managed workstations and servers can enforce process-level and identity-aware policies, which covers the managed part of the estate well. They cannot run on the devices that matter most. Typical OT and IoMT endpoints (infusion pumps, PLCs, building-automation controllers, imaging systems, access-control panels) do not accept a third-party agent. The embedded OS, the manufacturer warranty, and the real-time operating constraints forbid it. Agents secure the devices you could already patch and leave uncovered exactly the devices you cannot, which are the critical assets the frameworks are written to protect.

Compliance frameworks tolerated these trade-offs for years because the math made them tolerable. Slow vulnerability discovery gave organizations time to compensate with other controls. The AI-accelerated threat model changes that math. The frameworks have not shifted. The cost of continuing to defer identity-aware, agentless enforcement at the network layer has.

NIST SP 800-207: zero trust architecture

NIST SP 800-207 defines zero trust through a Policy Decision Point / Policy Enforcement Point (PDP/PEP) model. The PDP evaluates access requests against identity, context, and policy. The PEP enforces the decision at the point of access. Identity-based microsegmentation platforms implement the PDP/PEP model by centralizing policy decisions in a cloud or on-premises control plane (the PDP) and enforcing those decisions at the network switch level (the PEP), where every port becomes an enforcement point.

Section 3.1 of SP 800-207 describes three deployment approaches. Approach #2, micro-segmentation, places enforcement at the network infrastructure layer rather than at the application or endpoint. Section 3.2.3 describes a resource portal-based model where no agent is required on the accessing device. Combined, these two sections describe an architecture in which agentless microsegmentation is enforced through existing network switches, with no software required on the protected endpoints themselves.

SP 800-207 identifies seven tenets of zero trust. Any compliant microsegmentation solution must address all seven:

• Per-session access evaluation requires a dynamic policy engine that reassesses device posture continuously, not just at connection time.
• "No resource is inherently trusted" maps to a default-deny enforcement posture where traffic is blocked unless explicitly permitted.
• "Collect as much information as possible about the current state of assets" demands an identity correlation engine that aggregates data from multiple sources (CMDB, EDR, MDM, vulnerability scanners) to build comprehensive device profiles for attribute-based access control (ABAC).

The framework is vendor-agnostic by design. What matters is that the chosen implementation can enforce identity-based policy at the network layer, covers managed and unmanaged devices equally, and does not require agents on the endpoints it protects. As a compensating control, SP 800-207's micro-segmentation approach provides the network-layer enforcement that substitutes for endpoint-resident controls on devices that cannot host them; this is the exact gap the unpatchable-device population creates. For sequencing guidance, the NIST SP 800-207 micro-segmentation deployment approach walk-through covers the decision tree, and the broader Zero Trust Architecture implementation guide maps the tenets to an enterprise rollout.

NIST CSF 2.0: mapping microsegmentation to six functions

CSF 2.0 organizes cybersecurity activities into six functions: Govern, Identify, Protect, Detect, Respond, and Recover. A comprehensive microsegmentation solution should address subcategories across all six functions, not just Protect.

The most direct mapping is PR.IR-01, which calls for organizations to "segment by platform type (IT, IoT, OT)." This requires device classification by genre or platform type, with policy enforcement tied to that classification. Devices should be grouped into segmentation zones based on device class, type, and role, ensuring that an IoT sensor and an IT workstation on the same physical switch are treated as fundamentally different asset types.

As a compensating control, PR.IR-01 is the CSF 2.0 subcategory that substitutes network-layer segmentation for endpoint-resident protections that IoT and OT devices cannot accept. What separates strong microsegmentation implementations from minimal ones is dual coverage of PROTECT and DETECT functions. When every switch port acts as both a policy enforcement point and a monitoring sensor, the same infrastructure that blocks unauthorized lateral movement also provides visibility into actual communication patterns. This feeds the DETECT function without requiring separate monitoring infrastructure, a meaningful operational efficiency. (If your segmentation solution cannot tell you what is actually happening on the network, you are flying blind with the cockpit lights off.)

IEC 62443: industrial automation and control systems

IEC 62443 is the governing framework for industrial cybersecurity, and its zones and conduits model (ISA/IEC 62443-3-2) is the foundation of OT network segmentation. Zones group assets with common security requirements. Conduits define allowed communication paths between zones.

Any microsegmentation solution targeting IEC 62443 compliance must implement these constructs: logical security zones that mirror OT architecture (without requiring physical network redesign), conduit rules that define precisely which communications are permitted between zones, and enforcement through existing industrial network infrastructure. The enforcement mechanism must be agentless. You cannot install endpoint software on a PLC that runs a 15-year-old embedded RTOS.

ISA/IEC 62443-3-3 explicitly addresses compensating countermeasures for brownfield OT environments where primary controls (including patching) cannot be applied. Network-layer segmentation enforced through existing switches is precisely this type of compensating control. A PLC that communicates only with its historian and engineering workstation, and never reaches the corporate network, has its blast radius contained regardless of its patch status. That is the whole point.

Our IEC 62443 network segmentation requirements analysis covers the control-level detail, and the Elisity IEC 62443 segmentation white paper maps each 62443-3-3 service requirement to the corresponding enforcement capability. For engineering teams building the OT asset picture underneath, CISA's 2025 OT asset inventory guidance is the companion reference most auditors now expect.

HIPAA 2025 NPRM, HHS 405(d)/HICP, and FDA Section 524B

The healthcare regulatory picture shifted in 2025. The HIPAA 2025 Notice of Proposed Rulemaking introduced 45 CFR 164.312(a)(2)(vi), a proposed mandatory network segmentation requirement. This is new. Previous HIPAA security rules referenced access controls but did not explicitly require network segmentation. (Note: As of this writing, the 2025 NPRM remains a proposed rule and has not been finalized. Organizations should track the rulemaking process, but the direction of travel is clear.)

HHS 405(d) Health Industry Cybersecurity Practices (HICP) go further. Practices #6 and #9 explicitly name microsegmentation as the recommended control for legacy and unmanaged medical devices. These are devices running embedded operating systems that cannot accept endpoint agents, exactly the devices that AI-accelerated vulnerability discovery puts at greatest risk.

FDA Section 524B establishes cybersecurity requirements for medical device manufacturers, but the installed base problem falls to Healthcare Delivery Organizations (HDOs). For IoMT devices already deployed (infusion pumps, patient monitors, imaging systems) HDOs need compensating controls because manufacturers may not or cannot provide patches. Identity-based microsegmentation is that compensating control.

For the control-by-control walk-through, the 2025 HIPAA Security Rule network segmentation requirements analysis covers the mapping from old rule to new, and the HHS 405(d) HICP segmentation guidance walks through how each practice maps to enforcement architecture. For incident disclosure context, the CIRCIA healthcare reporting obligations summary describes how segmentation documentation and incident disclosure intersect. For a peer reference, the Southern Illinois Healthcare microsegmentation case study documents a 400-bed deployment across a regional health system.

PCI DSS 4.0: microsegmentation compliance for cardholder data

PCI DSS has required network segmentation since its earliest versions, but 4.0 sharpens the requirements. Requirements 1.2 through 1.5 mandate segmentation controls for any network that processes, stores, or transmits cardholder data. Appendix B provides guidance on compensating controls for legacy payment systems that cannot meet standard requirements directly.

The operational challenge in PCI environments is scope. Every system on a flat network that touches the cardholder data environment (CDE) is in scope for PCI compliance, which means every system requires assessment, hardening, and ongoing monitoring. Microsegmentation reduces scope by isolating the CDE at the identity level. Devices that are not in the payment segmentation group cannot reach cardholder data systems, and those devices drop out of PCI scope. (Fewer systems in scope means fewer audit hours, fewer controls to maintain, and fewer things that can go wrong during an assessment.)

The key differentiator for microsegmentation versus traditional VLAN-based PCI segmentation: VLANs provide broadcast domain separation, but devices within the same VLAN, or misconfigured inter-VLAN routes, can still reach each other. Identity-based policy groups enforce access based on what a device is, not where it sits on the network. For a vertical-specific example, the PCI DSS network segmentation across bank branches case study shows how identity-based Policy Groups reduce audit scope across distributed retail-banking environments.

CISA Zero Trust Maturity Model v2.0: the capstone framework

In July 2025, CISA declared microsegmentation "a critical component of ZTA" applicable to "any technology environment: IT, OT, ICS, IoT." This is the broadest mandate of any framework; it applies to every device class, every vertical, every organization that falls under CISA guidance.

CISA's maturity model defines four levels: Traditional, Initial, Advanced, and Optimal. Achieving Optimal maturity in the Network pillar requires microsegmentation across all device classes, not just managed IT endpoints, but unmanaged IoT, OT controllers, and IoMT devices. Ask yourself: does your current segmentation solution cover the devices that cannot run an agent? If the answer is no, you are stuck below Optimal.

This is the capstone framework. Where NIST provides architectural guidance, IEC 62443 addresses industrial environments, HIPAA covers healthcare, and PCI covers payment systems, CISA ZTMM applies to all of them. And its requirement is unambiguous: you need microsegmentation that covers every device type. For a planning-phase walk-through, see CISA microsegmentation in zero trust, part one: introduction and planning.

How Elisity implements identity-based enforcement

Compliance frameworks describe what must be done. This section describes how Elisity does it.

Discovery. IdentityGraph discovers devices using DHCP, CDP/LLDP, MAC address analysis, and traffic flow analysis. No agents. No supplicants. Every connected device (managed laptops, unmanaged IoT sensors, OT controllers, medical devices, guest endpoints) appears in the asset inventory automatically.

Classification. Each device is classified by Genre (IT, OT, IoT, IoMT), Category (across 24 types), Type, Vendor, and OS. Elisity Intelligence performs this classification natively using AI/ML analysis of network flows, DHCP, CDP/LLDP, MAC/OUI, and other telemetry already present on the switch. No third-party dependency is required to build the baseline. IdentityGraph then optionally enriches that baseline with data from 25+ connectors, including identity providers such as Active Directory and Microsoft Entra ID (supporting both on-premises and cloud directories), alongside CrowdStrike, Claroty, Dragos, Armis, Nozomi, Asimily, Tenable, ServiceNow, and others, which add use-case context rather than base identity: this PLC drives the Line-3 assembly cell or this imaging workstation is at a regional clinic, not the main hospital. The result is a multi-source identity profile that no single compromised data source can spoof.

Policy. Administrators create identity-based policies using AND/OR logic across 50+ attributes. Policies bind to device identity, not IP addresses. When a device moves between switch ports, changes IPs via DHCP, or roams across sites, its policy follows it. Policy Simulation mode lets administrators validate rules against real traffic before enforcement, preventing disruptions in production environments.

Enforcement. The Virtual Edge (VE) translates identity-based policies into switch-native enforcement and programs the VEN (the onboarded switch) out-of-band. The switch enforces natively at every port. Default-deny posture means devices can only communicate with explicitly permitted destinations. The VE operates at the control plane, separate from and independent of the data path.

Monitoring. Every VEN is both an enforcement point and a monitoring sensor. The Traffic Flow Visualization Matrix shows actual communication patterns between Policy Groups, providing continuous visibility that feeds both compliance reporting and incident detection.

Three policy examples across verticals:

Constraints and considerations

Microsegmentation is a powerful compensating control, but it is not a silver bullet. Organizations evaluating any microsegmentation solution should understand these constraints before deployment.

The 9 percent problem

What blocks the other 91 percent is complexity. Traditional microsegmentation approaches require endpoint agents (which cannot run on OT/IoT/IoMT), new hardware (firewalls, overlay appliances), VLAN redesigns, re-IPing projects, and months of professional services. For organizations with thousands of unmanaged devices across dozens of sites, these requirements turn microsegmentation from a security control into a multi-year infrastructure program.

Agentless, switch-level enforcement changes the equation. Elisity enforces through the switches already in production: Cisco, Juniper, Arista, HPE Aruba. No agents to deploy on devices that cannot run them. No new hardware to rack. No VLAN redesigns. No re-IPing.

Typical deployment timeline: two weeks of planning and architecture, two days of Virtual Edge deployment, one week or more of policy rollout and simulation. Individual sites go live in three to four hours without downtime. This is the difference between microsegmentation as a three-year initiative and microsegmentation as a quarter's project.

The six frameworks covered in this paper do not give organizations three years. The HIPAA 2025 proposed NPRM sets compliance deadlines (pending finalization). PCI DSS 4.0 requirements are already in effect. CISA's Optimal maturity level is the stated target for federal agencies. The operational question is not whether to microsegment (the frameworks have answered that) but whether the deployment model allows organizations to get there before the next AI-accelerated discovery hits their devices.

What to do now

Four actions for security leaders evaluating microsegmentation against these frameworks:

1. Inventory your unpatchable attack surface. Identify every device that cannot receive patches: end-of-life medical devices, legacy OT controllers, decade-old firmware, embedded IoT sensors. Elisity's IdentityGraph builds this inventory natively via Elisity Intelligence (AI/ML on flows and telemetry, with no agent and no inline appliance), and customers who already run Claroty, Dragos, Armis, or similar asset-intelligence platforms can layer that data in as enrichment for additional use-case context. You cannot segment what you cannot see.

2. Segment highest-risk devices immediately. Do not wait for a perfect architecture. Isolate OT from IT. Restrict medical device communications to required clinical systems. Contain legacy payment terminals to their cardholder data paths. Start with the devices that carry the most risk and the least patching capability.

3. Evaluate agentless microsegmentation. Prioritize solutions that enforce through existing switches at the network layer. If your microsegmentation approach requires agents, it cannot cover the devices that need protection most. Assess identity-based policy models that follow devices rather than IP addresses.

4. Pressure-test lateral movement prevention. Run tabletop exercises that assume zero-day compromise of an unpatchable device. Can an attacker reach crown jewels from that compromised device? If yes, that device and that path are your deployment priority. If AI-accelerated vulnerability discovery can find zero-days in decades-old code for under $50, your threat model must assume compromise of every unpatched device on your network. The same blast-radius logic applies to agentic AI systems operating with machine-speed authority inside the network; identity-based microsegmentation is the containment control for both populations.

The Glasswing moment did not create the problem. It quantified the economics. AI-discovered zero-days cost less than a dinner out. The frameworks already told us what to do about it. The remaining question is execution speed.

Frequently asked questions

Does NIST 800-207 require microsegmentation?

NIST SP 800-207 names micro-segmentation as one of three core deployment approaches for zero trust architecture in Section 3.1. It does not require micro-segmentation as the only approach; organizations can also pursue enhanced identity governance or software-defined perimeter deployments. However, for environments with significant IoT, OT, or IoMT populations, micro-segmentation combined with the Section 3.2.3 resource portal model is frequently the only approach that realizes the architecture without agents on every device. The seven tenets in Section 2.1 (per-session access, dynamic policy, monitoring of all assets) apply regardless of which deployment approach you choose.

What does the HIPAA 2025 Security Rule require for network segmentation?

The HIPAA 2025 NPRM introduces 45 CFR 164.312(a)(2)(vi), which makes network segmentation a required technical safeguard rather than a discretionary implementation option. Covered entities and business associates must demonstrate that ePHI-handling systems are segmented from non-clinical systems, that the segmentation is enforced at the network layer, and that enforcement is auditable. This supplements existing access control requirements under 45 CFR 164.312(a)(1). Organizations that previously relied on VLAN-based segmentation as a general access control now need segmentation that stands up to the specific technical-safeguard standard: identity-bound, enforced, and logged.

Does IEC 62443 require separation of OT and IT networks?

Yes. ISA/IEC 62443-3-2 requires that control-system assets be grouped into zones with common security requirements, with all inter-zone traffic flowing through explicitly defined conduits. ISA/IEC 62443-3-3 SR 5.1 requires logical segmentation of control-system networks from non-control-system networks, and SR 5.2 requires that zone boundaries be monitored and controlled. For brownfield environments where patching is not feasible, IEC 62443-3-3 permits compensating countermeasures. Identity-based microsegmentation enforced through existing industrial switches is one recognized compensating control that satisfies SR 5.1 and SR 5.2 without requiring dedicated OT firewalls at every zone transition.

Does CISA ZTMM apply microsegmentation to IoT and OT?

Yes. CISA ZTMM v2.0 states that microsegmentation applies to any technology environment, including IT, OT, ICS, and IoT. Achieving Optimal maturity in the Network pillar requires microsegmentation across all device classes, including unmanaged IoT sensors, OT controllers, ICS systems, and IoMT devices, with continuous monitoring and automated response. This forecloses strategies that rely exclusively on agent coverage, because agents cannot reach the unmanaged device classes ZTMM scopes into the requirement.

Can identity-based microsegmentation reduce PCI DSS scope?

Yes, when the segmentation is demonstrable under PCI DSS 4.0 segmentation testing. PCI scope covers any system that can reach the cardholder data environment on a flat network. Identity-based Policy Groups isolate the CDE at the device-identity level rather than the VLAN level, so devices outside the payment Policy Group cannot reach payment systems regardless of physical port or subnet. Scope reduction requires assessor validation: testing must demonstrate that non-CDE devices cannot reach CDE devices and that the result is repeatable. Identity-based segmentation typically fares better than VLAN-based approaches because the policy binding does not depend on topology that drifts over time.

How does HHS 405(d) name microsegmentation as a required control?

HHS 405(d) Health Industry Cybersecurity Practices name microsegmentation in Practice #6 (network management) and Practice #9 (medical device security) as the recommended control for legacy and unmanaged medical devices. Unlike general segmentation guidance that allows a range of approaches, 405(d) names the control specifically and scopes it to the IoMT population where endpoint agents cannot be installed. For organizations aligning to the HIPAA 2025 NPRM, 405(d) is the prescriptive layer that tells you which control the Security Rule's general segmentation requirement expects for medical devices.

Appendix: consolidated control mapping tables

A.0 Quick reference: "Does Elisity map to framework X?"

A single-page reference for field teams answering RFI, RFP, and compliance-audit questions. Each row links the framework's compensating-control language to the Elisity capability that satisfies it. Detailed mappings follow in A.1 through A.7.

For each framework section above, refer to the detailed mapping tables A.1 through A.7 below for control-by-control evidence.

A.1 NIST SP 800-207: zero trust architecture seven tenets

A.2 NIST SP 800-207: logical component mapping

A.3 NIST CSF 2.0: subcategory mapping by function

A.4 IEC 62443: zones, conduits, and compensating controls

A.5 HIPAA 2025 NPRM + HHS 405(d)/HICP + FDA Section 524B

A.6 PCI DSS 4.0: network segmentation requirements

A.7 CISA Zero Trust Maturity Model v2.0: network pillar

References: NIST SP 800-207 · NIST CSF 2.0 · ISA/IEC 62443 · HIPAA 2025 NPRM · HHS 405(d) HICP · FDA Section 524B · PCI DSS 4.0 · CISA ZTMM v2.0

For additional context on AI-driven vulnerability discovery and the unpatchable-device problem: Claude Mythos found 27-year-old bugs. Your unpatchable devices are exposed.

Further reading

• What is microsegmentation?
• Claude Mythos AI vulnerability discovery and microsegmentation
• NIST SP 800-207 micro-segmentation deployment approach
• Zero trust architecture implementation guide
• IEC 62443 network segmentation requirements in 2025
• HIPAA 2025 Security Rule network segmentation requirements
• PCI DSS network segmentation across bank branches
• CISA microsegmentation in zero trust: introduction and planning
• Southern Illinois Healthcare microsegmentation case study
• AI agent network security and microsegmentation in 2026
• How to secure IoT devices