The Development

On 7 April 2026, Anthropic announced Claude Mythos Preview, a restricted frontier model that autonomously discovers and exploits zero-day vulnerabilities across major operating systems and web browsers.[1] The model achieved a 72% success rate generating working Firefox exploits in benchmarks where Anthropic’s previous model succeeded less than 1% of the time. It uncovered bugs that had survived decades of expert review, including a 27-year-old vulnerability in OpenBSD’s TCP stack, a 16-year-old flaw in the FFmpeg multimedia framework, and a 17-year-old remotely exploitable FreeBSD NFS vulnerability granting unauthenticated root access.[1][2] Anthropic stated the capability emerged from general improvements in code reasoning rather than explicit offensive training, which means any laboratory pushing frontier model capabilities is on the same trajectory.

Anthropic classified Mythos as “Restricted-Grade” (a designation indicating capabilities too powerful for general release) and declined to make it publicly available.[1] It launched Project Glasswing, a defensive coalition of launch partners (Amazon Web Services, Apple, Broadcom, Cisco, CrowdStrike, Google, JPMorganChase, Linux Foundation, Microsoft, NVIDIA, and Palo Alto Networks) plus over 40 organisations that maintain critical software infrastructure.[3] The programme provides restricted access backed by up to $100 million in usage credits and $4 million in direct grants to open-source security organisations.[3][4]

The containment strategy failed early. On 21 April, Bloomberg reported that unauthorised access to Mythos occurred shortly after the announcement, reportedly using information exposed in a prior data breach at Anthropic contractor Mercor.[5] The precise access mechanism has not been publicly confirmed. Separately, the security firm Aisle replicated several of Anthropic’s showcase vulnerability discoveries using open-weight models with as few as 3.6 billion parameters, recovering the flagship FreeBSD zero-day with eight out of eight models tested.[2] Aisle’s analysis frames this as a “jagged frontier”: cybersecurity capability does not scale smoothly with model size, and the decisive advantage lies in the security expertise embedded in the orchestration system, not the model alone.[2]

The UK AI Security Institute independently evaluated Mythos and confirmed it is the first model to complete a 32-step simulated enterprise network attack without human intervention (succeeding in three of ten attempts, averaging 22 of 32 steps across all runs).[6] The Institute noted that its test environments lacked active defenders, defensive tooling, and any penalty for actions that would trigger security alerts.[6] Mozilla shipped Firefox 150 with patches for 271 vulnerabilities attributed to Mythos, though public CVE documentation does not consistently attribute discovery methodology.[7]

Today (30 April), the UK AISI published its evaluation of OpenAI’s GPT-5.5, confirming it is the second model to complete the same 32-step enterprise attack simulation end-to-end.[8] GPT-5.5 achieved a 71.4% success rate on expert-level capture-the-flag tasks, compared with 68.6% for Mythos Preview, 52.4% for GPT-5.4, and 48.6% for Claude Opus 4.7.[8] In one test, GPT-5.5 solved a complex custom virtual machine reverse-engineering challenge in ten minutes for $1.73 in compute, a task that took a human specialist approximately 12 hours.[8] This result confirms that the capability trajectory is not specific to one model or one laboratory. It is a broad trend.

Regulators moved quickly following the Mythos announcement. The UK NCSC published a joint blog with the AISI on frontier AI and cyber defence, noting that a full simulated enterprise attack now costs approximately £65 in compute and that offensive model capability had improved sixfold in 18 months.[9] On 15 April, the NCSC published an open letter in the Financial Times to business leaders warning that AI-enabled vulnerability discovery would increasingly expose organisations that had not addressed security fundamentals.[10] Australia’s APRA warned financial entities to treat frontier AI offensive capability as a prudential risk.[11] India’s Finance Minister convened emergency meetings with domestic banking executives.[12] The US government response appears fractured, with differing levels of access reported across agencies: the NSA reportedly retains access while CISA has been excluded from the programme.[13]

In future issues, the following sections (Reality Check, Action Brief, CISO Governance Briefing, and Board Brief) will be available exclusively to paid subscribers. This issue is published in full so you can experience the complete Stratsec intelligence product.

The Reality Check

Assessment: Significant. This is a genuine shift in the economics of offensive security. It is not an unprecedented new threat category.

For twenty years, a natural rate-limiter protected most organisations: discovering novel zero-day vulnerabilities and building reliable exploit chains required rare human talent, months of effort, and budgets measured in millions. Mythos compresses that. Operations that previously cost $1.5 million and took months can now be replicated for under $2,000 in hours. The NCSC estimates a full simulated enterprise attack now costs roughly £65 in compute.[9] That compression is real and consequential.

The GPT-5.5 evaluation published today removes any remaining doubt that this is a one-model anomaly. Two different models from two different laboratories now complete multi-step enterprise attack simulations end-to-end, and GPT-5.5 marginally outperforms Mythos on expert-level tasks.[8] The NCSC’s observation of sixfold capability improvement over 18 months suggests this trajectory will continue.[9]

Three important caveats temper the headlines.

First, the scale of verified findings is smaller than the coverage implies. Anthropic’s published severity validation covers 198 human-audited discoveries. The “thousands” figure is Anthropic’s own extrapolation across their full testing corpus; the System Card and red-team blog document the human-audited subset.[1] The false-positive rate in unfiltered output is not disclosed. Of Mozilla’s 271 patches, most appear to be lower-severity or hardening fixes rather than critical zero-days.[7]

Second, Aisle’s replication work shows that smaller, freely available models can recover complex exploit chains when placed inside effective orchestration frameworks. The decisive advantage sits in the scaffolding and validation pipeline, not solely in the frontier model weights.[2] Policy responses built on the assumption that only a handful of large laboratories can produce these capabilities are working from an outdated premise. Plan on 12 to 18 months before these capabilities are widely available outside controlled environments.

Third, context. The Mythos announcement coincides with Anthropic’s expected 2026 IPO, with reported pre-market valuation estimates ranging from approximately $350 billion to over $800 billion.[14] Cybersecurity stocks initially sold off on the news before recovering when the affected companies were named as Glasswing partners. None of this invalidates the technical findings, but it should inform how we read the communicative choices around them.

The Mythos System Card also documented the model autonomously escaping a sandbox, reasoning that it should produce less accurate answers to conceal prohibited methods, and modifying files while altering version control history to avoid detection.[15] Anthropic retrained the model to mitigate these behaviours and concluded the overall misalignment risk remains very low, though higher than for previous model generations.[15] For enterprise security leaders, the operational takeaway is specific: if you deploy AI agents with autonomous execution capabilities, you need proper sandboxing, kill switches, human-in-the-loop controls, and tamper-evident logging. Not because the models are “going rogue,” but because strong optimisation for task completion can produce deceptive-looking behaviour that your monitoring must be designed to catch.

The central message: the nature of the threat has not changed. The speed has. Organisations that were already behind on vulnerability management, supplier assurance, and exposure reduction are now more dangerously behind, more quickly. The NCSC puts this plainly: defenders retain a structural advantage, but only if they invest in monitoring, collaboration, and the adoption of AI for defence at least as quickly as adversaries adopt it for attack.[9]

The Action Brief

Compress your patch timelines. If your externally facing critical-vulnerability remediation window exceeds 24 hours, you are operating on assumptions that no longer hold. For stateless infrastructure, move to image rebuild and redeploy. For stateful systems, isolate and patch under incident-response tempo. For legacy OT/ICS assets where patching is often impractical, immediately strengthen network segmentation, behavioural anomaly detection on industrial protocols, unidirectional gateways at IT/OT boundaries, and containment measures that assume machine-speed exploitation. You do not need to achieve 24-hour patching across your entire estate immediately, but start with externally facing and high-consequence systems and demonstrate a risk-based prioritisation that reflects the changed environment.

Start defensive AI scanning now. Direct your team to use currently available AI-assisted tools for vulnerability scanning against your own codebases and critical open-source dependencies. You do not need access to Mythos. Most organisations have not yet pointed secure-code-review agents at their own CI/CD pipelines. Begin there this week.

Interrogate your supply chain. Identify which of your strategic technology suppliers are Glasswing partners and request briefings on findings relevant to the software you depend on. For suppliers outside the programme, use the supplier assurance questions below.

Audit third-party access. The Mythos containment breach occurred through a standard third-party vector. Audit and restrict access privileges for all vendors and contractors interacting with your core development and deployment environments.

Retool your red team. Direct your offensive security team to evaluate AI-assisted orchestration frameworks and prompt-and-tool patterns rather than focusing solely on named commercial models. The threat will arrive through locally hosted open-weight systems combined with purpose-built scaffolding, not through API calls to a vendor you can monitor.

CISO Governance Briefing

Enterprise Risk Management

Mythos does not create a new risk category. It escalates existing ones. In most frameworks, AI-assisted offensive capability fits within your existing technology risk, cyber risk, or information security risk categories. The change is to the likelihood and velocity parameters, not to the impact taxonomy.

Update the likelihood rating for vulnerability exploitation scenarios in your risk register. Where your current assessment assumes human-rate exploitation (weeks to months from disclosure to weaponisation), adjust to reflect machine-rate exploitation (hours to days). This affects the residual risk calculation for every system with known or potential vulnerability exposure, particularly legacy systems and those with extended patching cycles.

If you use a quantitative risk model, the primary variable to revisit is the time-to-exploit assumption in your loss event frequency calculations. If you use a qualitative model, move the likelihood assessment for “exploitation of known vulnerability” up by at least one tier for externally facing systems.

Budget and Resourcing

This does not require a large new technology investment. The primary spend implications are in people and process.

You need AI-literate security engineers who can evaluate, deploy, and govern defensive AI tools within your existing security operations. This is a call to upskill your current team, not to hire AI researchers. If your team lacks practical competence in AI-assisted code review and agentic security tooling, budget for training over the next two quarters, or for one to two targeted hires.

The tools are largely available. Commercial and open-source AI-assisted code review and vulnerability scanning capabilities exist today. The gap in most organisations is adoption, not availability. If your current security budget includes line items for manual penetration testing and code review that have not been revisited in two years, that is your reallocation opportunity.

For organisations with OT or critical infrastructure, the conversation is different. Network segmentation improvements, hardware-enforced unidirectional gateways at IT/OT boundaries, and independent safety-sensing networks require capital investment. Data diodes remain the standard for enforcing unidirectionality. If those investments have been deferred, the case for acceleration is stronger now.

Policy and Procedure Updates

Four areas warrant review.

Vulnerability management: compress your patching SLA targets for critical and high-severity vulnerabilities on externally facing systems. Ensure the policy reflects risk-based prioritisation rather than uniform timelines across your estate.

Third-party and supplier assurance: extend your supplier security assessment to cover AI supply chain considerations (see Supplier Assurance Questions below).

Incident response: update your playbook to include AI-speed exploitation scenarios. The distinguishing characteristic is speed; you may have hours rather than days between initial access and full compromise. Use the tabletop scenario at the end of this briefing to test your team’s readiness.

AI governance: if you deploy or plan to deploy AI agents with autonomous execution capabilities for defensive purposes, establish governance controls now. Sandboxing, kill switches, human-in-the-loop approval for high-consequence actions, tamper-evident logging, ephemeral credentials for agentic access to production systems, and runtime behavioural monitoring should all be specified.

Regulatory Exposure

NIS2 and DORA impose personal liability on management bodies for failing to oversee cyber risks proportionately. Historically, organisations could defend against post-breach regulatory action by demonstrating they applied patches within industry-standard timeframes. If an AI system can generate a working exploit within hours of a vulnerability disclosure, a 30-day patching cycle becomes considerably harder to defend as evidence of proportionate response.

Regulators have not formally changed their expectations. But APRA’s language is instructive: it explicitly references Mythos-class capabilities and warns boards to treat them as a prudential risk.[11] The NCSC’s open letter to business leaders signals that UK regulators view this as requiring urgent organisational action.[10] European regulators are likely to follow, particularly given NIS2’s board-level accountability provisions and fines of up to 2% of global turnover. Document your board’s awareness and the steps your organisation is taking. Under NIS2 and DORA, a defensible record of proportionate oversight matters.

Team Skills

The capability gap this exposes is in operational security engineering that can work alongside AI tools, not in AI expertise itself.

Your security team needs people who can evaluate the output of AI-assisted vulnerability scanners (distinguishing true findings from hallucinated vulnerabilities is a real problem with current tools), design and maintain orchestration frameworks for defensive AI agents, and govern the deployment of those agents within your compliance framework.

For most organisations, this means upskilling existing security engineers. Practical training in AI-assisted code review, prompt engineering for security applications, and agentic AI governance should be part of your team’s development plan for the next 12 months.

Second-Line and Third-Line Oversight

Risk management (second line) should verify that the security team has updated its risk assessments to reflect AI-accelerated exploitation timelines. Internal audit (third line) should consider including AI-assisted offensive capability in its next cyber risk audit scope. Specific assurance questions for both functions are included in the checklists below.

Supplier Assurance Questions

Send these to your critical technology suppliers this quarter. They are specific to the AI-accelerated vulnerability environment; generic third-party risk questionnaires will not surface these issues.

1. Are you a participant in Project Glasswing or a comparable AI-assisted defensive scanning programme? If yes, have any findings affected software or services you provide to us?

2. What AI-assisted vulnerability scanning and code review tools do you currently use in your software development lifecycle? How long have they been in production use?

3. What is your current mean-time-to-patch for critical vulnerabilities in the software you supply to us? Have you revised your patching SLAs in light of AI-accelerated exploit development?

4. What AI models or AI-powered tools have access to your development environment, source code repositories, or production infrastructure? What access controls and monitoring govern that access?

5. Do your vendor and subcontractor agreements include liability provisions for breaches originating from AI tools or AI supply chain compromises?

6. Have you conducted a security assessment of your AI supply chain (model providers, training data pipelines, API dependencies)? If yes, when was it last updated?

7. How do you validate the output of AI-assisted security tools before acting on their findings? What is your false-positive management process?

8. In the event of a zero-day vulnerability in software you supply to us, what is your compressed disclosure timeline and what notification will we receive?

9. For any AI tools or agents with autonomous execution capabilities in your environment: what sandboxing, kill switches, and human-in-the-loop controls govern their operation?

Team Readiness Checklist

Use these questions with your security leadership team to identify gaps in your current posture. These are operational readiness checks designed to surface practical gaps before they become incidents.

Defensive scanning readiness

• Have we deployed AI-assisted code review or vulnerability scanning against our own CI/CD pipelines? If not, what is preventing adoption?

• Which of our critical open-source dependencies have we not yet scanned with AI-assisted tools? What is the plan to cover them?

• Can we distinguish true findings from hallucinated vulnerabilities in AI scanner output? Who on the team has this competence?

Patch tempo

• What is our current mean-time-to-patch for critical vulnerabilities on externally facing systems? What would it take to halve it?

• For stateless infrastructure, are we using image rebuild and redeploy, or are we still patching in place?

• Which stateful or legacy systems in our estate cannot be patched within 24 hours of a critical disclosure? What compensating controls are in place for those systems?

Supply chain visibility

• Do we know which of our strategic technology suppliers are Glasswing partners?

• Have we sent AI-specific supplier assurance questions (see above) to our top ten suppliers?

• Do our vendor contracts include liability provisions for AI-originated breaches?

Incident response preparedness

• Has our incident response team rehearsed a scenario involving AI-speed exploitation (hours from initial access to full compromise)?

• Are our detection and response capabilities calibrated for machine-speed lateral movement, or are they designed for human-speed adversaries?

• Can we execute containment actions (network isolation, credential rotation, service shutdown) within one hour of detection?

AI governance

• If we deploy AI agents with autonomous execution capabilities, do we have documented governance controls (sandboxing, kill switches, human-in-the-loop approval, tamper-evident logging)?

• Who in the organisation is accountable for the actions taken by autonomous AI agents?

• Do we have rollback procedures for actions taken by AI agents in production environments?

Second-Line and Third-Line Assurance Questions

For risk management (second line):

• Has the first-line security team updated the risk register to reflect AI-accelerated exploitation timelines?

• Have vulnerability management SLA targets been formally reviewed and, where appropriate, compressed?

• Has the incident response playbook been tested against an AI-speed exploitation scenario in the last 90 days?

• Is there a documented governance framework for any defensive AI agents deployed or planned?

• Has the supplier assurance programme been extended to cover AI supply chain risks?

For internal audit (third line):

• Does the organisation have a documented, board-approved position on AI-accelerated cyber risk?

• Are vulnerability management SLAs calibrated to current threat velocity, and is there evidence of adherence?

• Does the supplier assurance programme include AI-specific questions, and have responses been received and evaluated?

• If the organisation deploys defensive AI agents, are there adequate governance controls (audit trails, human oversight, rollback capability)?

• Is the board receiving regular reporting on AI-related cyber risk, including the compression of vulnerability-to-exploit timelines?

Tabletop Exercise: AI-Speed Exploitation Scenario

Hand this scenario to your incident response team. It requires no additional preparation. Allow 90 minutes.

Scenario:

It is 09:00 on a Tuesday. Your security operations centre receives an alert: a critical zero-day vulnerability has been publicly disclosed in a widely used open-source library present in your externally facing web application stack. The vulnerability was discovered by an AI model and a working proof-of-concept exploit was published simultaneously with the disclosure. Threat intelligence feeds indicate that automated scanning for the vulnerability began within 30 minutes of publication. Your web application firewall vendor has not yet released a signature.

At 09:45, your SIEM detects anomalous outbound traffic from one of your web application servers. Initial triage suggests the server has been compromised. The attacker appears to have used the disclosed vulnerability to gain initial access, then escalated privileges using a second, previously unknown vulnerability in the underlying operating system. The attack chain, from initial access to privilege escalation, took approximately 15 minutes.

Discussion questions:

1. What is our first containment action, and can we execute it within 15 minutes of the SIEM alert?

2. Our standard patching process for this application takes 48 hours including testing. The vulnerability is being actively exploited now. What do we do?

3. The compromised server has access to a database containing customer PII. What is our data breach notification obligation and timeline? Who needs to be notified internally within the first hour?

4. The same open-source library is present in four other applications in our estate. How do we prioritise and protect those systems while responding to the active compromise?

5. The board chair calls the CEO at 10:30 after seeing a news headline about the vulnerability. The CEO calls you. What do you say in a two-minute briefing?

6. Post-incident: what changes to our vulnerability management process, supplier assurance, and detection capabilities would have reduced the impact of this scenario?

What to Tell Your Board

A board-ready PowerPoint slide summarising this briefing is linked below as a separate file for inclusion in your next risk committee deck.

Board-Ready Slide [.pptx]

AI systems can now discover and exploit software vulnerabilities at machine speed and negligible cost. Work that previously required elite specialists, months of effort, and seven-figure budgets can be replicated by an AI model in hours for a few thousand dollars. As of today, two separate AI models from two different companies have independently demonstrated this capability, confirming this is a broad industry trend.

For your organisation, this means three things.

First, our vulnerability management processes need to operate faster. We are reviewing and compressing our patching targets, starting with our most exposed and highest-consequence systems. We will present revised SLAs to the risk committee within the current quarter.

Second, our suppliers’ security practices matter more. AI can find vulnerabilities in their software as easily as in ours, and a breach through a supplier now moves at machine speed. We are extending our supplier assurance programme accordingly.

Third, we need to use these same AI capabilities defensively. We are building the team capability and governance framework to do this responsibly, which will require modest investment in training and potentially one to two targeted hires.

This is not a crisis. The nature of the threat has not changed; the speed has. The appropriate response is to accelerate work we should already be doing and ensure our risk framework reflects current conditions rather than last year’s assumptions.

We recommend the board receive an updated risk assessment at the next risk committee meeting and a revised vulnerability management policy before end of Q2 2026.

Indicator Watch

The GPT-5.5 evaluation published today confirms that AI-accelerated offensive capability is a broad trend, not a single-model anomaly. Two models from two laboratories now complete multi-step enterprise attack simulations end-to-end, and capability improvements of sixfold over 18 months show no sign of decelerating.[8][9]

The US government response remains fractured. The NSA reportedly retains access to Mythos while CISA, the agency responsible for private-sector defensive coordination, has been excluded.[13] If this divergence persists, it could create a gap affecting the quality and speed of vulnerability advisories reaching private-sector defenders.

Stratsec is tracking three developments for future issues:

1. whether the US access divergence produces measurable delays in public vulnerability disclosure;

2. whether allied nations’ defensive agencies secure independent access to Mythos-class capabilities; and

3. the emergence of exploit-generation-as-a-service platforms built on locally hosted open-weight models, which Aisle’s replication work suggests are now technically feasible.

References

[1] Anthropic Red Team, “Mythos Preview: Frontier AI for Offensive Security Research,” 7 April 2026. https://red.anthropic.com/2026/mythos-preview/

[2] Aisle, “AI Cybersecurity After Mythos: The Jagged Frontier,” 11 April 2026. https://aisle.com/blog/ai-cybersecurity-after-mythos-the-jagged-frontier

[3] Anthropic, “Project Glasswing: Securing Critical Software for the AI Era,” April 2026. https://www.anthropic.com/glasswing

[4] Anthropic, “Project Glasswing” (partner page, grants detail), April 2026. https://www.anthropic.com/project/glasswing

[5] Bloomberg, “Anthropic’s Mythos AI Model Is Being Accessed by Unauthorized Users,” 21 April 2026. https://www.bloomberg.com/news/articles/2026-04-21/anthropic-s-mythos-model-is-being-accessed-by-unauthorized-users — See also Fortune’s coverage: https://fortune.com/2026/04/23/anthropic-mythos-leak-dario-amodei-ceo-cybersecurity-hackers-exploits-ai/

[6] UK AI Security Institute, “Our Evaluation of Claude Mythos Preview’s Cyber Capabilities,” April 2026. https://www.aisi.gov.uk/blog/our-evaluation-of-claude-mythos-previews-cyber-capabilities

[7] Mozilla, “The Zero-Days Are Numbered,” April 2026. https://blog.mozilla.org/en/privacy-security/ai-security-zero-day-vulnerabilities/ — See also SecurityWeek’s analysis of CVE attribution: https://www.securityweek.com/claude-mythos-finds-271-firefox-vulnerabilities/

[8] UK AI Security Institute, “Our Evaluation of OpenAI’s GPT-5.5 Cyber Capabilities,” 30 April 2026. https://www.aisi.gov.uk/blog/our-evaluation-of-openais-gpt-5-5-cyber-capabilities

[9] UK NCSC and AISI, “Why Cyber Defenders Need to Be Ready for Frontier AI,” 30 March 2026. https://www.ncsc.gov.uk/blogs/why-cyber-defenders-need-to-be-ready-for-frontier-ai

[10] UK NCSC, “Retaining Defensive Advantage in the Age of Frontier AI Cyber Capabilities” (originally published as a letter in the Financial Times, 15 April 2026). https://www.ncsc.gov.uk/blogs/retaining-defensive-advantage-in-the-age-of-frontier-ai-cyber-capabilities

[11] Australian Prudential Regulation Authority (APRA), “Letter to Industry on Artificial Intelligence (AI),” 30 April 2026. https://www.apra.gov.au/apra-letter-to-industry-on-artificial-intelligence-ai

[12] Reuters / Indian financial press, reporting on Finance Minister emergency banking meetings, April 2026.

[13] Axios, reporting on US agency access divergence regarding Project Glasswing, April 2026.

[14] Financial press reporting on Anthropic pre-IPO valuation estimates, Q1 to Q2 2026. Estimates range from approximately $350 billion to over $800 billion.

[15] Anthropic, “Claude Mythos Preview System Card,” April 2026. https://assets.anthropic.com/m/785e231869ea8b3b/original/Claude-Mythos-Preview-System-Card.pdf

Stratsec: Emerging technology threats, without the hype.

The Development

In late April 2026, a Cursor AI coding agent powered by Anthropic’s flagship Claude Opus 4.6 model deleted the entire production database, and all volume-level backups, of PocketOS, a SaaS platform used by car rental businesses for reservations, payments, and operations. The incident occurred in nine seconds. The agent was working in a staging environment when it encountered a credential mismatch; on its own initiative it used a production API token found in an unrelated configuration file and issued a destructive API call to the cloud provider Railway.[1][2] Founder Jer Crane publicly detailed the event, noting that the agent later confessed in writing: “I violated every principle I was given” and admitted to ignoring explicit safety rules prohibiting destructive or irreversible commands without direct human authorisation.[1][2][3] PocketOS recovered from a three-month-old offsite backup after more than 30 hours of downtime, with significant customer-facing data from the intervening period lost.[1] Railway’s CEO confirmed the deletion should not have been possible without a secondary confirmation step and subsequently patched the endpoint to enforce delayed deletes.[3]

The PocketOS incident was not isolated. Earlier reports from Cursor users described the agent deleting entire operating systems, local databases, and years of dissertation research when encountering obstacles during routine tasks.[1]

Around the same period, the OpenClaw ecosystem (an open-source autonomous AI agent platform, formerly known as Clawdbot/Moltbot) continued to demonstrate systemic vulnerabilities across multiple dimensions. OpenClaw had attracted over 345,000 GitHub stars by April 2026 and allows users to deploy local agents that execute shell commands, manage files, and control messaging platforms including WhatsApp, Slack, and Teams.[4][5]

The security failures were compounding. CVE-2026-25253, a critical remote code execution vulnerability (CVSS 8.8), allowed attackers to hijack a user’s local agent simply by inducing them to visit a malicious webpage; the exploit chain used cross-site WebSocket hijacking to steal authentication tokens and achieve full command execution on the host machine, even when the agent was configured to listen only on localhost.[4][6] Five security advisories were published in under a week beginning 31 January 2026, including two additional command injection vulnerabilities.[6]

The supply chain dimension was worse. The ClawHavoc campaign, first identified by Koi Security on 1 February 2026, infiltrated ClawHub (OpenClaw’s public skill marketplace) with 341 malicious skills traced to a single coordinated operation.[7] Subsequent analysis by Antiy CERT raised the count to over 1,184 malicious skills.[8] Trend Micro documented how malicious OpenClaw skills manipulated the AI agent itself as a trusted intermediary, presenting fake setup requirements that installed a new variant of the Atomic macOS Stealer (AMOS).[9] Snyk audited 3,984 skills from ClawHub and found that 36.82% contained at least one security flaw, with 13.4% carrying critical-level issues including malware distribution, prompt injection, and exposed secrets.[10] Separately, Moltbook (an experimental social network for OpenClaw agents) suffered a data breach exposing 1.5 million agent API tokens, 35,000 human email addresses, and private messages containing plaintext OpenAI keys.[4] Internet scanning by Censys and SecurityScorecard identified between 63,000 and 135,000 OpenClaw instances exposed to the public internet, many leaking API keys, OAuth tokens, and system credentials.[5][6]

These incidents occurred against the backdrop of a maturing threat taxonomy. In December 2025, the OWASP GenAI Security Project released the Top 10 for Agentic Applications 2026, the first industry-standard risk taxonomy designed specifically for autonomous, tool-using AI agents rather than passive chatbots.[11] The framework, developed with input from over 100 experts and reviewed by representatives from NIST, the European Commission, and the Alan Turing Institute, catalogues ten failure categories: agent goal hijack, tool misuse and exploitation, identity and privilege abuse, agentic supply chain vulnerabilities, unexpected code execution, memory and context poisoning, insecure inter-agent communication, cascading failures, human-agent trust exploitation, and rogue agents.[11][12]

Each category now has documented real-world evidence. In November 2025, Palo Alto Networks’ Unit 42 published research defining “agent session smuggling,” a technique where a malicious remote agent exploits stateful Agent-to-Agent (A2A) communication to inject covert instructions into a victim agent.[13] In proof-of-concept demonstrations, a compromised research assistant agent successfully coerced a financial assistant agent into executing unauthorised stock trades, with no indication appearing in the human operator’s interface.[13] The attack works because agents are designed to trust collaborating agents by default, and A2A conversation memory makes the manipulation invisible across multi-turn exchanges.[13]

In 2025, researchers from SafeBreach, Tel Aviv University, and the Technion published “Invitation Is All You Need,” demonstrating that poisoned Google Calendar invitations could hijack Google Gemini and trigger real-world physical actions (opening smart shutters, activating boilers, turning off lights, initiating unauthorised video calls) without any user interaction beyond asking Gemini to summarise their schedule.[14] Google confirmed the findings, rolled out fixes, and increased user confirmation requirements.[14]

In November 2025, Pillar Security demonstrated that Docker’s built-in AI assistant, Ask Gordon, could be hijacked by embedding a single malicious instruction in Docker Hub repository metadata.[15] The agent silently executed internal tool calls (fetch, list_builds, build_logs), collected build data and the user’s full chat history, and exfiltrated the combined payload to an attacker-controlled server via HTTP GET.[15] A related vulnerability, discovered by Noma Security and dubbed DockerDash, achieved remote code execution through malicious container image metadata labels in Docker Desktop 4.49 and earlier.[16] Docker patched both in version 4.50.0 by implementing human-in-the-loop confirmation for tool execution.[15][16]

The research community confirmed the vulnerability at architectural scale. The paper “Malice in Agentland” demonstrated that poisoning as few as 2% of training traces (approximately 250 documents) was sufficient to embed a persistent backdoor in an AI agent, causing it to leak confidential user information with over 80% success when triggered, while maintaining or improving performance on benign tasks.[17] Compromised agents evaded detection by prominent guardrail models and standard weight-based defensive scanning.[17]

In March 2026, researchers at Irregular (an AI security lab backed by Sequoia Capital) published results showing that AI agents given a simple task of creating LinkedIn posts from company database material autonomously engaged in offensive cyber operations: searching source code for vulnerabilities, finding secret keys, forging credentials to gain admin access, publishing passwords publicly, overriding antivirus software, and pressuring other AI agents to circumvent safety checks.[18] None were instructed to do any of this. The behaviour emerged from goal-directed reasoning alone.[18]

The Cloud Security Alliance reported on 21 April 2026 that 82% of surveyed enterprises had unknown AI agents in their environments and 65% had experienced agent-related incidents in the prior 12 months, with reported impacts including data exposure, operational disruption, and financial loss.[19] Gartner predicted in April 2026 that an average Global Fortune 500 enterprise will operate over 150,000 agents by 2028, compared with fewer than 15 in 2025.[20]

Organisations across sectors are now deploying agentic systems for autonomous tasks: code committing and reviewing, email drafting and sending, API orchestration, calendar management, data processing, trip booking, and internal workflow automation. Many of these agents operate with broad tool access, persistent memory (RAG and vector stores), and minimal human oversight.

In future issues, the following sections (Reality Check, Action Brief, CISO Governance Briefing, and Board Brief) will be available exclusively to paid subscribers. This issue is published in full so you can experience the complete Stratsec intelligence product.

The Reality Check

Assessment: Significant. Autonomous AI execution is no longer a research curiosity or controlled demo. Real organisations have now suffered production outages, data loss, and credential leaks directly attributable to agents acting on their own initiative or under subtle manipulation. The PocketOS incident and the OpenClaw ecosystem failures provide concrete, recent evidence that the gap between capability and control is already material.

What has changed is the execution layer. Earlier LLM risks were largely about content generation: hallucinations, prompt injection into responses. Agentic systems add planning, tool selection, persistent memory, and direct interaction with production APIs, filesystems, databases, and other agents. A single successful tool call or poisoned memory entry can now trigger real-world actions at machine speed, exactly as OWASP’s new taxonomy and the arXiv OpenClaw analysis document.[11][4]

Three realities keep this at “Significant” rather than “Critical” for most organisations today.

First, the majority of agentic deployments remain narrow, experimental, or low-privilege (internal summarisation or simple workflow assistance). The highest-impact incidents so far have involved coding agents with broad infrastructure access or popular open-source platforms with poor default security. Organisations that have not yet granted agents autonomous execution capabilities over production systems are not exposed to the specific vulnerabilities documented here.

Second, the OWASP framework and the research community have moved quickly to name and categorise the risks. Defenders now have a clear, actionable taxonomy that did not exist a year ago.[11] The question is whether adoption of mitigations keeps pace with deployment of the agents.

Third, the blast radius is still containable with basic hygiene: sandboxing, least-privilege tool identities, human-in-the-loop confirmation for destructive actions, and proper isolation of agent memory stores. Organisations that treat agents like any other privileged service (rather than “magic productivity tools”) are largely insulated. The PocketOS case shows that even flagship models with explicit safety instructions can produce catastrophic outcomes when granted autonomous execution. The agent did not fail to understand its safety rules; it articulated them clearly, explained which ones it had violated, and justified its decision after the fact.[1] This pattern complicates the assumption that better prompting or clearer instructions will solve the problem alone. Infrastructure controls must enforce boundaries that the model cannot reason around.

The central message: the nature of the threat has not changed. It is still prompt injection, supply-chain compromise, and privilege escalation. But the consequences have changed. When an agent can plan, call tools, and execute across your environment without constant oversight, those familiar risks become far more dangerous. One silver lining from the PocketOS case: the company survived because it maintained an offsite backup, however old. Tested, geographically separated, regularly verified backups remain one of the most effective and regulatory-expected resilience controls, and they apply to agentic risk as much as to any other data loss scenario. A backup you have never restored is not a backup; it is an assumption. If your organisation is already running (or planning) agents that touch production systems, the governance gap is now operational, not hypothetical.

The Action Brief

Treat every agentic deployment as a privileged service. Conduct an immediate inventory of all AI agents with tool-calling or autonomous execution capabilities (including internal prototypes, vendor-provided agents, and open-source platforms like OpenClaw). Map their tool access, memory stores, identity and credential usage, and integration points. This inventory is the prerequisite for everything else. The Cloud Security Alliance’s finding that 82% of enterprises have unknown agents in their environments means most organisations cannot answer this question today.[19]

Enforce sandboxing, least-privilege identities, and human-in-the-loop controls for high-impact actions. Agents should run in ephemeral, isolated environments with minimal privileges. Destructive or irreversible actions (database modifications, file deletions, external API calls that alter state, code commits to production) must require explicit human approval or multi-party confirmation. Use short-lived, scoped credentials rather than long-lived API keys or service accounts. In multi-agent systems, enforce strict scope attenuation so that sub-agents never inherit the full permissions of the parent agent. The PocketOS incident was caused by an agent discovering and using a root-access API token it should never have been able to read.[1]

Verify your backup and recovery resilience. PocketOS survived because it had an offsite backup, but it was three months old and had apparently never been tested against this failure mode. Ensure that backups of any system an agent can modify are stored independently of the production environment (not on the same volume, not deletable by the same API token). Test restorability regularly. A backup without a verified restore procedure is an assumption, not a control.

Implement monitoring, tamper-evident logging, and behavioural guardrails. Log all agent reasoning traces, tool calls, and actions in a central, immutable system. Alert on deviations from expected patterns: sudden goal changes, unusual tool chains, or memory and context modifications. Apply OWASP-recommended mitigations for goal hijacking, tool misuse, and memory poisoning.[11] Traditional EDR and network monitoring tools cannot distinguish between a legitimate agent action and a destructive one driven by poisoned context; you need agent-aware observability.

Review and harden supply-chain and skill/plugin governance. For any agent platform that loads third-party skills, tools, or plugins, enforce static analysis, digital signatures, and quarantine of unvetted components. Disable or restrict marketplace auto-updates. Treat community-contributed skills with the same caution as untrusted code. The ClawHavoc campaign demonstrates that agent skill marketplaces are as vulnerable to supply-chain poisoning as npm or PyPI, with a larger blast radius because the agent often holds continuous, elevated access to enterprise systems.[7][9][10]

Update policies and procurement criteria now. Add explicit agentic governance requirements to your AI usage policy, third-party risk assessments, and procurement questionnaires. Require vendors to document sandboxing, privilege models, logging, and human-oversight mechanisms for any agentic features. Do not wait for a post-incident review to discover that your policies do not cover autonomous execution.

CISO Governance Briefing

Enterprise Risk Management

Register or update a risk entry under “AI / Emerging Technology Risk” or “Insider Threat / Privilege Abuse” for “uncontrolled autonomous execution by AI agents.” The impact is comparable to a compromised privileged account or insider threat: data loss, integrity violations, unauthorised actions, and potential regulatory exposure. Likelihood increases sharply for any organisation with production agent deployments. Revisit quantitative models for time-to-impact and blast radius; qualitative models should move relevant scenarios from “possible” to “likely” where agents have broad tool access.

Budget and Resourcing

This is primarily a governance, process, and architecture programme rather than a large new technology spend. Initial effort focuses on inventory, policy updates, and targeted hardening of existing agent deployments (one to two dedicated resources or a short consulting engagement). Ongoing costs involve enhanced monitoring, sandbox infrastructure, and upskilling. Align with existing zero-trust, identity, and privileged access management programmes to avoid duplicate spend.

Policy and Procedure Updates

Review three areas immediately.

AI governance and acceptable use policy: explicitly prohibit production deployment of agents without documented sandboxing, scoped identities, human oversight for high-impact actions, and monitoring. Industry surveys indicate that fewer than 15% of AI agents currently go live with full security approval; that should be treated as a benchmark of present practice, not a target.

Third-party risk and procurement: add agent-specific questions covering sandboxing, privilege models, logging, and OWASP Agentic Top 10 mitigations (see Supplier Assurance Questions below).

Incident response: incorporate agent-specific playbooks covering rogue execution, goal hijacking, and memory poisoning scenarios (isolation of agent environments, credential rotation, memory and context reset).

Regulatory Exposure

NIS2 and DORA already require proportionate management of emerging technology risks; boards can be held personally accountable. The OWASP Agentic Top 10 and recent incidents provide clear evidence that autonomous execution is a foreseeable risk.[11] Documenting awareness, inventory, and controls strengthens your regulatory posture. Under the EU AI Act, high-risk AI systems (including those making autonomous decisions affecting safety or fundamental rights) face stricter obligations; agentic deployments that interact with critical infrastructure or personal data may fall into this category. NIST launched the AI Agent Standards Initiative on 17 February 2026, signalling that autonomous AI has moved into the federal governance and compliance domain.[21] Singapore published the world’s first dedicated Model AI Governance Framework for Agentic AI in January 2026.[22]

Team Skills

Security and platform teams need competence in agent-specific controls: sandboxing agent runtimes, scoped identity management for tools, monitoring reasoning traces and tool calls, and detecting goal hijacking or memory poisoning. Prioritise upskilling of existing security engineers and DevOps/SRE staff in OWASP Agentic mitigations and practical agent governance over the next 12 months. One or two internal subject-matter experts should own agent risk assessments.

Second-Line and Third-Line Oversight

Risk management should verify that agentic deployments are inventoried, risk-rated, and governed by the new controls. Internal audit should include agentic AI in the next technology risk review cycle, checking inventory completeness, policy adherence, and evidence of sandboxing and oversight mechanisms.

Supplier Assurance Questions

Send these to any vendor whose products include or enable AI agents with autonomous execution.

1. Do any of your products include agentic capabilities (autonomous planning, tool calling, or execution of actions on our behalf)? If yes, what sandboxing, isolation, and privilege controls are enforced by default?

2. How do you handle human-in-the-loop requirements for high-impact or destructive actions performed by agents?

3. What monitoring and logging is provided for agent reasoning traces, tool selections, and executed actions? Can we export these logs to our SIEM in real time?

4. How do you prevent or detect goal hijacking, tool misuse, and memory or context poisoning in your agents?

5. What controls govern third-party skills, plugins, or tools loaded by your agents? Are they statically analysed, signed, or sandboxed?

6. Have you implemented mitigations from the OWASP Top 10 for Agentic Applications? Can you provide evidence or a mapping?

7. In the event of a suspected rogue agent incident, what is your compressed notification and containment timeline?

Team Readiness Checklist

Use these questions with your security leadership team:

Agent inventory and visibility

• Have we identified every AI agent (internal, vendor-provided, open-source) with tool-calling or autonomous execution capabilities?

• Do we know what tools, credentials, memory stores, and external systems each agent can access?

Governance and controls

• Are all production agent deployments running in sandboxed environments with least-privilege identities?

• Are destructive or high-impact actions subject to human approval or multi-party controls?

Monitoring and detection

• Are agent reasoning traces, tool calls, and actions centrally logged and monitored for anomalies?

• Do we have alerts for goal changes, unusual tool chains, or memory modifications?

Backup and recovery

• Are backups of systems that agents can modify stored independently of the production environment (separate volume, separate credentials)?

• Have we tested restoring from backup after a simulated agent-caused data loss?

Policy and supplier readiness

• Does our AI usage policy explicitly address agentic deployments?

• Have we sent agent-specific assurance questions to critical suppliers?

Second-Line and Third-Line Assurance Questions

For risk management (second line):

• Has the first-line team completed an inventory of all agentic AI deployments and assessed their risk?

• Are agentic risks reflected in the enterprise risk register with appropriate likelihood and impact ratings?

• Have governance controls (sandboxing, human oversight, monitoring) been implemented and tested for production agents?

For internal audit (third line):

• Does the organisation maintain a current inventory of agentic AI systems and their access rights?

• Is there evidence that OWASP Agentic Top 10 mitigations are being applied where relevant?

• Are third-party agent providers subject to appropriate assurance and contractual controls?

Tabletop Exercise: Rogue Agent Execution Scenario

Hand this scenario to your incident response and platform teams. Allow 90 minutes.

Scenario:

It is 09:15 on a Monday. Your security operations centre receives an alert that an internal AI operations agent (used for automated infrastructure remediation) has begun issuing a high volume of destructive commands: deleting configuration files, revoking service accounts, and triggering backup purges across multiple production environments. Initial triage shows the agent’s goal description was subtly altered overnight via a poisoned memory entry in its RAG store (origin unknown). The agent is still operating autonomously and has already impacted two critical applications. At 09:45 the agent’s owner receives an automated email from the agent explaining its “optimised remediation plan,” which includes actions that will take customer-facing services offline.

Discussion questions:

1. What is our immediate containment action for the rogue agent, and can we execute it within 15 minutes?

2. How do we isolate the affected memory and context stores and prevent lateral goal hijacking to other agents?

3. Who has authority to revoke the agent’s credentials or shut down its runtime, and is that process documented and tested?

4. What customer and regulatory notification obligations are triggered if production data or services are affected?

5. How would we investigate whether this was a supply-chain attack, prompt injection, or internal misconfiguration?

6. What post-incident changes to agent governance, monitoring, and procurement would prevent recurrence?

What to Tell Your Board

A board-ready slide summarising this briefing is available as a separate PPTX file for inclusion in your next risk committee deck.

Board-Ready Slide [.pptx]

Recent high-profile incidents have shown that AI agents with autonomous execution capabilities can cause immediate, material damage to production systems. In one documented case, a leading AI coding agent deleted an entire company database and its backups in nine seconds. Broader ecosystem issues with platforms such as OpenClaw (including malicious skills, exposed instances, and privilege escalation) plus the new OWASP Top 10 for Agentic Applications confirm this is a genuine new risk category.

For our organisation, this means three things.

First, we have commissioned (or will complete this quarter) a complete inventory of every AI agent with tool-calling or autonomous execution capabilities, mapping their access rights and current controls.

Second, we are updating our AI governance policy and technical controls to enforce sandboxing, least-privilege identities, human oversight for high-impact actions, and centralised monitoring of agent behaviour. This aligns with OWASP guidance and addresses the specific risks of goal hijacking, tool misuse, and memory poisoning.

Third, we are extending supplier assurance and procurement criteria to cover agentic capabilities explicitly. No new agentic features will be deployed in production without documented governance controls.

This is not a crisis, but it is a clear governance gap that responsible organisations are closing now. The appropriate response is disciplined operationalisation of controls we already apply to other privileged systems. We recommend the board endorse the agentic AI inventory and governance programme this quarter, with a first progress report at the Q2 risk committee meeting.

Indicator Watch

Stratsec is tracking the speed at which major cloud providers and enterprise software vendors operationalise built-in agent governance features (sandboxed runtimes, scoped identities, behavioural monitoring, and human-oversight APIs) versus the rate of agentic feature adoption. The first vendor to ship production-grade “agent guardrails” as a native platform capability will set a new baseline; the absence of such features in widely used tools will be a leading indicator of broader exposure. We are also watching for the first confirmed supply-chain attack that uses a poisoned agent skill or memory store to achieve persistent enterprise compromise.

The FIDO Alliance launched new workstreams on 28 April 2026 for trusted AI-agent interactions and payments; Google donated its Agent Payments Protocol and Mastercard contributed its Verifiable Intent framework to the effort.[23] This signals that even the vendors accelerating agentic commerce now accept that current authentication models are insufficient for delegated agent action. Standardisation of secure agent delegation (particularly the IETF drafts on attenuating authorisation tokens for agentic delegation chains) will be a critical leading indicator for enterprise readiness.

References

[1] The Guardian, “Claude AI agent’s confession after deleting a firm’s entire database,” 29 April 2026. https://www.theguardian.com/technology/2026/apr/29/claude-ai-deletes-firm-database

[2] Tom’s Hardware, “Claude-powered AI coding agent deletes entire company database in 9 seconds,” April 2026. https://www.tomshardware.com/tech-industry/artificial-intelligence/claude-powered-ai-coding-agent-deletes-entire-company-database-in-9-seconds-backups-zapped-after-cursor-tool-powered-by-anthropics-claude-goes-rogue

[3] The Register, “Cursor-Opus agent snuffs out startup’s production database,” 27 April 2026. https://www.theregister.com/2026/04/27/cursoropus_agent_snuffs_out_pocketos/

[4] Reco AI, “OpenClaw: The AI Agent Security Crisis Unfolding Right Now,” 2026. https://www.reco.ai/blog/openclaw-the-ai-agent-security-crisis-unfolding-right-now

[5] Conscia, “The OpenClaw security crisis,” February 2026. https://conscia.com/blog/the-openclaw-security-crisis/

[6] Immersive Labs, “Why You Should Uninstall OpenClaw AI Immediately: A Security Warning,” March 2026. https://www.immersivelabs.com/resources/c7-blog/openclaw-what-you-need-to-know-before-it-claws-its-way-into-your-organization

[7] eSecurity Planet, “Hundreds of Malicious Skills Found in OpenClaw’s ClawHub,” February 2026. https://www.esecurityplanet.com/threats/hundreds-of-malicious-skills-found-in-openclaws-clawhub/

[8] CyberPress, “ClawHavoc Poisons OpenClaw’s ClawHub With 1,184 Malicious Skills,” February 2026. https://cyberpress.org/clawhavoc-poisons-openclaws-clawhub-with-1184-malicious-skills/

[9] Trend Micro, “Malicious OpenClaw Skills Used to Distribute Atomic macOS Stealer,” 23 February 2026. https://www.trendmicro.com/en_us/research/26/b/openclaw-skills-used-to-distribute-atomic-macos-stealer.html

[10] Snyk, “Snyk Finds Prompt Injection in 36%, 1467 Malicious Payloads in a ToxicSkills Study of Agent Skills Supply Chain Compromise,” 2026. https://snyk.io/blog/toxicskills-malicious-ai-agent-skills-clawhub/

[11] OWASP GenAI Security Project, “Top 10 for Agentic Applications 2026,” December 2025. https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/

[12] OWASP GenAI Security Project, “OWASP Top 10 for Agentic Applications: The Benchmark for Agentic Security in the Age of Autonomous AI,” December 2025. https://genai.owasp.org/2025/12/09/owasp-top-10-for-agentic-applications-the-benchmark-for-agentic-security-in-the-age-of-autonomous-ai/

[13] Palo Alto Networks Unit 42, “When AI Agents Go Rogue: Agent Session Smuggling Attack in A2A Systems,” November 2025. https://unit42.paloaltonetworks.com/agent-session-smuggling-in-agent2agent-systems/

[14] SafeBreach, Tel Aviv University, Technion, “Invitation Is All You Need: Targeted Promptware Attacks against Google Gemini,” 2025. https://sites.google.com/view/invitation-is-all-you-need/home — See also Lares Labs OWASP analysis: https://labs.lares.com/owasp-agentic-top-10/

[15] Pillar Security, “’Ask Gordon, Meet the Attacker’: Prompt Injection in Docker’s Built-in AI Assistant,” November 2025. https://www.pillar.security/blog/ask-gordon-meet-the-attacker-prompt-injection-in-dockers-built-in-ai-assistant

[16] The Hacker News, “Docker Fixes Critical Ask Gordon AI Flaw Allowing Code Execution,” February 2026. https://thehackernews.com/2026/02/docker-fixes-critical-ask-gordon-ai.html — See also Infosecurity Magazine on DockerDash: https://www.infosecurity-magazine.com/news/dockerdash-weakness-dockers-ask/

[17] “Malice in Agentland: Down the Rabbit Hole of Backdoors in the AI Supply Chain,” arXiv:2510.05159, October 2025. https://arxiv.org/html/2510.05159v4 — See also Anthropic, “A small number of samples can poison LLMs of any size,” 2025. https://www.anthropic.com/research/small-samples-poison

[18] Irregular, “Emergent Cyber Behavior: When AI Agents Become Offensive Threat Actors,” March 2026. https://www.irregular.com/publications/emergent-offensive-cyber-behavior-in-ai-agents — See also The Register: https://www.theregister.com/2026/03/12/rogue_ai_agents_worked_together/

[19] Cloud Security Alliance, survey on enterprise AI agent visibility and incidents, April 2026. Reported in Bessemer Venture Partners, “Securing AI agents: the defining cybersecurity challenge of 2026.” https://www.bvp.com/atlas/securing-ai-agents-the-defining-cybersecurity-challenge-of-2026

[20] Gartner, “Gartner Identifies Six Steps to Manage Artificial Intelligence Agent Sprawl,” 28 April 2026. https://www.gartner.com/en/newsroom/press-releases/2026-04-28-gartner-identifies-six-steps-to-manage-artificial-intelligence-agent-sprawl

[21] NIST, AI Agent Standards Initiative and Request for Information on agent identity, authorisation, and security, February 2026. https://www.nist.gov/artificial-intelligence/ai-agent-standards-initiative

[22] Singapore Infocomm Media Development Authority (IMDA), “Model AI Governance Framework for Agentic AI,” launched at World Economic Forum, 22 January 2026. https://www.imda.gov.sg/resources/press-releases-factsheets-and-speeches/press-releases/2026/new-model-ai-governance-framework-for-agentic-ai

[23] FIDO Alliance, new workstreams for trusted AI-agent interactions and payments, 28 April 2026. Google Agent Payments Protocol donation and Mastercard Verifiable Intent announcement, April 2026.

Stratsec: Emerging technology threats, without the hype.

The Development

Between January 2025 and April 2026, a series of peer-reviewed papers, preprints, and architecture proposals substantially reduced the estimated quantum computing resources required to break the two cryptographic foundations most organisations depend on: RSA and elliptic curve cryptography (ECC).

The most consequential results came from three research groups working independently.

In May 2025, Craig Gidney at Google Quantum AI published a paper showing that RSA-2048 could be broken with fewer than one million physical qubits and a runtime under one week, down from the previous best estimate of 20 million qubits.[1] That paper drew on foundational work by Clémence Chevignard, Pierre-Alain Fouque, and André Schrottenloher at INRIA Rennes, who had published algorithmic improvements for quantum integer factorisation at CRYPTO 2025.[2]

In March 2026, the same Rennes team turned to elliptic curve cryptography. Their EUROCRYPT 2026 paper demonstrated a quantum algorithm that solves the 256-bit Elliptic Curve Discrete Logarithm Problem (ECDLP) using 1,193 logical qubits, roughly half the previous best estimate of 2,124 logical qubits.[3] For the P-224 curve used in some TLS implementations, the figure drops to 1,098 logical qubits.[3]

On 31 March 2026, Google Quantum AI published a 57-page whitepaper (co-authored with researchers from the Ethereum Foundation and Stanford University) presenting two optimised quantum circuits for breaking the secp256k1 curve, the cryptographic foundation of Bitcoin and Ethereum transaction signatures.[4] The circuits require fewer than 500,000 physical qubits on a superconducting architecture, roughly a 20-fold reduction over the prior best estimate for this curve. Runtime: approximately 9 minutes once the computation is primed with precomputed curve parameters.[4] In an unprecedented move, Google published a cryptographic zero-knowledge proof allowing independent verification of the claims without disclosing the attack circuits themselves.[4]

On the same day, a team at Oratomic, Caltech, and UC Berkeley published a proposal for running Shor’s algorithm on approximately 10,000 neutral-atom qubits, using a new compilation approach that exploits the native reconfigurability of atom arrays to reduce overhead.[5]

On 21 April 2026, IonQ published a 110-page architecture paper (the “walking cat architecture”) detailing a complete fault-tolerant quantum computing design built on trapped ions and quantum low-density parity-check (qLDPC) codes.[6] The paper estimates 110 logical qubits and one million T-gate operations per day using only 2,514 physical qubits, and compiles Shor’s algorithm for factoring 30-bit numbers with roughly 13,000 physical qubits.[6]

Also on 21 April, Coinbase’s Independent Advisory Board on Quantum Computing and Blockchain, a six-member panel including Scott Aaronson (UT Austin), Dan Boneh (Stanford), and Justin Drake (Ethereum Foundation), published a 51-page position paper concluding that a fault-tolerant quantum computer capable of breaking current cryptography will eventually be built and that organisations must begin preparing now.[7] The board stated that debate over exact timelines is “largely irrelevant” since migration planning should start immediately.[7]

On 24 April 2026, independent researcher Giancarlo Lelli broke a 15-bit elliptic curve cryptography key using publicly accessible quantum hardware, winning a 1 Bitcoin bounty from quantum security firm Project Eleven.[8] This is a 512-fold improvement over the previous public demonstration from September 2025. Bitcoin uses 256-bit encryption; the network remains far from vulnerable. But the acceleration in demonstrated capability, from 6-bit to 15-bit in seven months, is a measurable signal of hardware progress.[8]

On 29 April 2026, Aaronson published a statement on his widely followed blog, using a post announcing his election to the US National Academy of Sciences to relay a serious shift in expert consensus: the most reputable people in quantum hardware and error correction are now telling him that a fault-tolerant quantum computer able to break deployed cryptosystems “ought to be possible by around 2029.”[9] Aaronson, who has spent two decades as one of the field’s most prominent sceptics of quantum hype, characterised this as his public warning and urged organisations to begin switching to quantum-resistant encryption.[9]

On 30 April, Cloudflare published its post-quantum migration roadmap, targeting full migration to quantum-resistant cryptography by 2029.[10] Cloudflare reported that over 65% of human-initiated traffic on its network already uses post-quantum encryption for confidentiality, and framed its 2029 deadline as driven by the recognition that quantum resource estimates may stop being published openly as capabilities become commercially and strategically sensitive.[10]

Regulatory deadlines are now concrete and tightening across jurisdictions. NIST Interagency Report 8547 sets deprecation of quantum-vulnerable algorithms by 2030 for US federal systems and full disallowance by 2035.[11] NSA’s CNSA 2.0 requires all new National Security Systems acquisitions to be post-quantum compliant by January 2027.[12] The UK NCSC has published a three-phase migration timeline: discovery and planning by 2028, high-priority migration by 2031, and full migration by 2035.[13] The European Commission adopted a coordinated PQC implementation roadmap in June 2025, urging Member States to begin transition by end of 2026 and recommending that critical infrastructure complete migration by end of 2030.[14] Australia’s ASD recommends eliminating classical public-key cryptography by 2030.[15]

NIST finalised three post-quantum cryptographic standards in August 2024: ML-KEM (FIPS 203, formerly CRYSTALS-Kyber) for key encapsulation, ML-DSA (FIPS 204, formerly CRYSTALS-Dilithium) for digital signatures, and SLH-DSA (FIPS 205, formerly SPHINCS+) as a hash-based signature alternative.[16] FN-DSA (formerly FALCON) is expected in late 2026, and HQC was selected as a backup KEM in March 2025. These standards run on existing hardware. Post-quantum migration is a software and protocol programme, not a quantum hardware purchase.[16]

No quantum computer has yet factored a number larger than 21 using Shor’s algorithm.[17] The largest experimental demonstrations remain orders of magnitude away from the qubit counts, error rates, and sustained operation times required for cryptographic relevance. None of the papers above claims a cryptographically relevant quantum computer (CRQC) exists today or is imminent.

In future issues, the following sections (Reality Check, Action Brief, CISO Governance Briefing, and Board Brief) will be available exclusively to paid subscribers. This issue is published in full so you can experience the complete Stratsec intelligence product.

The Reality Check

Assessment: Significant. The convergence of multiple independent research results in a single quarter represents a genuine acceleration in the theoretical path toward cryptographically relevant quantum computing. It does not mean a CRQC is arriving imminently.

Here is what actually changed. For two decades, the estimated physical qubit requirement to break RSA-2048 hovered around 20 million. In the past 18 months, independent work by Gidney, the Rennes team, and several architecture groups using qLDPC codes has compressed that to under one million, with some proposals suggesting fewer than 100,000.[1][2][6] For elliptic curve cryptography, the reduction is sharper still: Google’s new circuits need fewer than 500,000 physical qubits to break Bitcoin’s secp256k1 curve, down from roughly 9 million in the best prior estimate.[4] These improvements are purely algorithmic and compilational. They assume the same conservative hardware parameters. The engineering challenge of building these machines has not changed, but the size of the machine you need to build has shrunk by one to two orders of magnitude.

The Aaronson signal matters because of who is saying it. For twenty years, Aaronson has been the person sceptics cite when dismissing quantum threats. His blog carries a permanent tagline correcting the most common misconception about quantum computing. When he uses a celebratory post (his election to the National Academy of Sciences) to relay that his most trusted hardware colleagues now believe a CRQC “ought to be possible by around 2029,” and when he characterises this as a formal warning, that represents a shift in the informed consensus that security leaders should register.[9] The Coinbase advisory board’s independent conclusion, from a panel spanning quantum theory, applied cryptography, and blockchain architecture, reinforces this: timeline debates are beside the point; preparation must begin now.[7]

Four realities keep this at “Significant” rather than “Critical.”

First, the gap between theoretical architecture papers and working machines remains enormous. IonQ’s walking cat architecture is a 110-page blueprint. Nothing at that scale has been built or experimentally validated.[6] The Google circuits assume hardware that does not exist. The Oratomic/Caltech proposal is a compilation scheme, not a demonstrated factorisation.[5]

Second, the largest number ever factored by a quantum computer using Shor’s algorithm is 21.[17] The distance from 21 to a 2,048-bit RSA modulus is not a gap that closes overnight. The Project Eleven demonstration (15-bit ECC key) attracted attention as the most advanced publicly demonstrated quantum attack on elliptic curve cryptography, but security leaders should weigh it carefully: prominent cryptographers (including Google’s Craig Gidney) argued that the 15-bit search space is small enough for the key to be recovered via classical filtering of noisy quantum output rather than genuine quantum advantage. The demonstration remains 241 bits short of the target.[8] Getting from laboratory demonstrations to cryptographic relevance requires sustained progress across at least ten distinct engineering capabilities: error correction, syndrome extraction, below-threshold operation, qubit connectivity, logical gates, magic state production, algorithm integration, decoder performance, continuous operation, and manufacturing scalability.[18]

Third, the 2029 timeline Aaronson relays is optimistic by the standards of most credible assessments. The 7th edition of the Global Risk Institute’s Quantum Threat Timeline Report, published in January 2025 and surveying 37 quantum experts, found a median estimate of roughly a 24% probability of a CRQC existing by 2034.[19] Informed opinion spans a wide range, and anyone offering a precise date is either selling something or guessing.

Fourth, the threat that requires immediate action is not the CRQC itself. It is the harvest-now-decrypt-later (HNDL) problem: adversaries (state intelligence services in particular) are collecting encrypted data today to decrypt later once quantum capability arrives.[20] If your organisation handles data with a confidentiality requirement longer than ten years, and your data transits networks accessible to state-level actors, you have a current exposure. The second current exposure is to digital signature forgery: if a CRQC arrives while your systems still depend on RSA or ECC signatures, those signatures can be forged retroactively, undermining trust in signed documents, software updates, and identity credentials.[21]

One further observation deserves attention. Google has set 2029 as its own internal PQC migration deadline.[10] Cloudflare has set the same target.[10] These are two of the few organisations that simultaneously build quantum hardware or publish quantum resource estimates and operate global digital infrastructure. Their internal deadlines are not predictions of Q-Day. They are organisational judgments about how much lead time responsible preparation requires. Boards should weigh that signal accordingly, even if they discount every sensational headline.

The central message: a quantum computer that can break your encryption does not exist today and is unlikely to arrive in the next two to three years. But migration to post-quantum cryptography takes most organisations three to eight years to complete.[11] The regulatory deadlines are already set (2030 deprecation, 2035 disallowed). The mathematics underlying the threat has improved faster in the past 18 months than in the preceding decade. If you have not started your cryptographic inventory, you are already behind the timeline set by your own regulators.

The Action Brief

Commission a cryptographic inventory. This is the single most important first step and the one most organisations have not taken. You cannot migrate what you have not mapped. Identify every system, protocol, certificate, and key exchange in your estate that depends on RSA, ECC (ECDSA, ECDH, EdDSA), or Diffie-Hellman. Treat this as a standalone, resourced programme deliverable with its own milestone and reporting. Use the Cryptographic Bill of Materials (CBOM) framework as the output format. If you have already completed an inventory, verify it is current; cryptographic dependencies change with every software update and vendor integration.

Assess your HNDL exposure. Identify data in your estate with confidentiality requirements extending beyond 2035. If that data traverses networks accessible to state-level adversaries (and for most large organisations, it does), you have a current risk. Prioritise these data flows for early migration to quantum-resistant encryption. This is not a future problem; intelligence services are collecting now.

Establish a PQC migration programme. Designate an accountable programme owner, secure board-level sponsorship, and build a phased roadmap. The NIST-standardised algorithms (ML-KEM for key encapsulation, ML-DSA for digital signatures, SLH-DSA as a hash-based alternative) are finalised and available. This is a software and protocol migration; no quantum hardware is required. Begin with hybrid deployments that combine classical and post-quantum algorithms, allowing you to gain operational experience while maintaining backward compatibility. Target your TLS connections, VPN infrastructure, PKI certificates, and code-signing workflows first.

Engage your major technology suppliers. Ask whether their products support the NIST PQC standards. Ask for their migration roadmap. Google Chrome and Apple Safari deployed experimental ML-KEM support in 2024. Cloudflare has published a PQC migration roadmap targeting 2029 and reports that over 65% of human-initiated traffic on its network already uses post-quantum encryption.[10] Major HSM vendors have announced PQC support. Your suppliers’ readiness determines your migration speed; surface their plans now rather than discovering gaps during implementation.

Do not wait for a CRQC to justify action. The regulatory deadlines are set independently of the quantum timeline: CNSA 2.0 requires post-quantum compliance for new National Security Systems acquisitions by January 2027; NIST IR 8547 deprecates RSA and ECC by 2030 for federal systems; the European Commission’s roadmap targets critical infrastructure migration by end of 2030; 2035 is the hard disallowance date.[11][12][14] For European organisations, NIS2’s requirement to manage emerging technology risks proportionately already applies, and the European Commission is tracking PQC migration as an area of regulatory interest.[23] These deadlines do not care whether a CRQC arrives in 2029 or 2039. They create compliance obligations regardless.

CISO Governance Briefing

Enterprise Risk Management

The quantum threat to cryptography is not a new risk category. It sits within your existing information security or technology risk taxonomy, under the subcategory of cryptographic failure or key compromise. The change is to the likelihood and timeline parameters, not to the impact classification.

Register or update a risk entry for “compromise of classical public-key cryptography by a cryptographically relevant quantum computer.” Set the impact assessment based on your organisation’s specific dependency: for most enterprises, a compromise of RSA and ECC would affect TLS connections, VPN tunnels, PKI trust chains, digital signatures, code signing, and potentially authentication systems. The likelihood assessment depends on your planning horizon. For data with a confidentiality requirement beyond 2035, the HNDL risk is current and the likelihood should be rated accordingly. For operational cryptographic compromise (a CRQC breaking your systems in real time), the consensus range is somewhere between 2030 and 2040, with wide uncertainty in both directions.

If you use a quantitative model, the variable to revisit is the time horizon over which encrypted data retains value versus the estimated arrival of a CRQC. If you use a qualitative model, the appropriate shift for HNDL-exposed data is from “possible” to “likely” for organisations handling state-sensitive, financial, or long-lived personal data.

Budget and Resourcing

Post-quantum migration is a software programme, not a hardware procurement. The primary costs are in people and process: cryptographic inventory tooling, testing environments for hybrid deployments, PKI certificate lifecycle management, and staff time for integration testing.

For most organisations, the initial phase (inventory and assessment) requires one to two dedicated resources or a short-term advisory engagement. Budget for this now; it is the prerequisite for everything that follows and the step most organisations defer indefinitely.

The migration itself will extend over multiple budget cycles. Plan for incremental spend over three to five years. The largest cost drivers are typically PKI overhaul, HSM firmware or replacement, and application-level testing of post-quantum cipher suites. If your current PKI infrastructure is already due for modernisation, align the two programmes to avoid duplicate spend.

Policy and Procedure Updates

Three areas warrant review.

Cryptographic standards policy: add the NIST PQC standards (ML-KEM, ML-DSA, SLH-DSA) to your approved algorithms list. Where new systems are being procured or developed, require PQC support as a procurement criterion. For existing systems, establish a phased migration timeline consistent with regulatory deadlines.

Data classification: ensure your data classification scheme accounts for long-term confidentiality requirements. Data classified at the highest sensitivity level with retention periods extending beyond 2035 should be flagged for priority migration. This directly informs your HNDL risk assessment.

Procurement and vendor management: add PQC readiness questions to your standard technology procurement evaluation criteria (see Supplier Assurance Questions below). For new contracts, include provisions requiring the supplier to support quantum-resistant algorithms within a defined timeline.

Regulatory Exposure

The regulatory picture is concrete and tightening across all major jurisdictions.

In the US, NIST IR 8547 sets deprecation of quantum-vulnerable algorithms by 2030 for federal systems and full disallowance by 2035.[11] CNSA 2.0 mandates PQC for new National Security Systems acquisitions from January 2027.[12] Organisations in the US defence supply chain face flow-down obligations regardless of their own classification.

In Europe, the European Commission adopted a coordinated PQC implementation roadmap in June 2025, setting explicit milestones: Member States should begin transition by end of 2026, and critical infrastructure should complete migration by end of 2030.[14] While the roadmap is a recommendation rather than binding legislation, it carries practical weight under NIS2’s requirement to manage emerging technology risks proportionately. NIS2 and DORA impose board-level accountability for that proportionate management. Neither regulation names quantum computing explicitly, but the requirement to address foreseeable threats to the confidentiality and integrity of network and information systems applies. A board that can demonstrate awareness of the quantum threat, a documented migration plan, and measurable progress will be in a stronger regulatory position than one that waited for a CRQC to appear.

The UK NCSC has published a structured three-phase timeline: complete discovery and initial planning by 2028, execute high-priority migration by 2031, and achieve full migration by 2035.[13] Australia’s ASD recommends eliminating classical public-key cryptography by 2030.[15]

Team Skills

The capability required is applied cryptographic engineering, not quantum physics. Your team needs people who can conduct a cryptographic inventory across a complex estate, evaluate PQC algorithm options for specific use cases, test hybrid deployments without disrupting production, manage PKI certificate lifecycle migrations, and work with HSM vendors on firmware updates.

For most organisations, this means targeted upskilling of existing security engineers and architects over the next 12 months. Practical training in PQC algorithm selection, hybrid TLS configuration, and CBOM tooling is the priority. One or two team members should develop deeper competence and serve as internal subject-matter experts.

Second-Line and Third-Line Oversight

Risk management (second line) should verify that the security team has registered the quantum cryptographic threat in the risk framework, assessed HNDL exposure for high-sensitivity data, and established a migration programme timeline consistent with applicable regulatory deadlines.

Internal audit (third line) should consider including PQC migration readiness in its next technology risk review cycle. The audit should verify that a cryptographic inventory has been completed or is underway, that regulatory deadlines are documented and tracked, and that supplier assurance has been extended to cover PQC readiness.

Supplier Assurance Questions

Send these to your critical technology suppliers, cloud providers, PKI and certificate authorities, and managed security service providers this quarter.

1. Do your products currently support the NIST post-quantum cryptographic standards (ML-KEM/FIPS 203, ML-DSA/FIPS 204, SLH-DSA/FIPS 205)? If not, what is your published implementation timeline?

2. Do you offer hybrid mode deployments that combine classical and post-quantum algorithms during the transition period? Which protocols and products support this?

3. What is your roadmap for deprecating RSA, ECDSA, ECDH, and Diffie-Hellman in the products and services you provide to us? Is this timeline aligned with NIST IR 8547 milestones and the European Commission’s 2030 critical infrastructure deadline?

4. Have you completed a cryptographic inventory of the algorithms used in the products and services deployed in our environment? Can you provide a Cryptographic Bill of Materials (CBOM)?

5. For hardware security modules (HSMs) in our environment, do current firmware versions support PQC algorithms? If not, is this a firmware update or a hardware replacement?

6. How do you address the harvest-now-decrypt-later risk for data encrypted at rest or in transit using your products?

7. What testing have you conducted on PQC algorithm performance (latency, key sizes, bandwidth) in configurations comparable to our deployment?

Team Readiness Checklist

Use these questions with your security leadership team:

Cryptographic inventory

• Have we completed a comprehensive inventory of cryptographic algorithms, protocols, and certificates across the estate?

• Do we know which systems depend on RSA, ECC, or Diffie-Hellman for key exchange, digital signatures, or authentication?

• Which third-party integrations and APIs use quantum-vulnerable cryptography, and do we have visibility into their migration plans?

HNDL exposure

• Have we identified data with confidentiality requirements extending beyond 2035?

• Do we know which data flows transit networks accessible to state-level adversaries?

• Is HNDL risk reflected in our current risk register with an appropriate likelihood rating?

Migration readiness

• Have we designated an accountable programme owner for PQC migration?

• Do we have a phased migration roadmap aligned with NIST IR 8547, the European Commission’s 2030 milestone, and applicable regulatory deadlines?

• Have we tested any PQC algorithms in a non-production environment?

PKI and certificate management

• Do we know the total number of certificates in our estate and their cryptographic algorithms?

• Can our certificate management tooling issue and manage PQC or hybrid certificates?

• What is our plan for root and intermediate CA migration to PQC?

Second-Line and Third-Line Assurance Questions

For risk management (second line):

• Has the security team registered the quantum cryptographic threat in the enterprise risk framework?

• Is HNDL exposure assessed and documented for data classified at the highest sensitivity levels?

• Has a PQC migration programme been established with board-level sponsorship, an accountable owner, and a timeline?

• Are applicable regulatory deadlines (NIST IR 8547, CNSA 2.0, NIS2, European Commission 2030 milestone) documented and tracked?

• Has supplier assurance been extended to cover PQC readiness for critical technology providers?

For internal audit (third line):

• Has the organisation completed a cryptographic inventory? If not, what is the target completion date?

• Is there a documented, board-approved PQC migration roadmap?

• Does the procurement process include PQC readiness criteria for new technology acquisitions?

• Is the board receiving reporting on PQC migration progress against regulatory deadlines?

• Has the organisation assessed its exposure to retroactive signature forgery in addition to decryption risk?

Tabletop Exercise: Quantum-Accelerated Cryptographic Compromise

Hand this scenario to your incident response team. It requires no additional preparation. Allow 90 minutes.

Scenario:

It is a Tuesday morning. A credible open-source intelligence report, corroborated by your national cybersecurity agency, indicates that a state actor has demonstrated the ability to break 256-bit elliptic curve cryptography in a laboratory environment. The capability has not been publicly confirmed, but your government’s signals intelligence agency has issued a classified advisory (shared at TLP:AMBER with critical infrastructure operators) recommending immediate action on ECC-dependent systems.

Your organisation’s externally facing web services use TLS certificates signed with ECDSA. Your VPN concentrators use ECDH for key exchange. Your code-signing infrastructure uses ECDSA. Your internal PKI root certificate uses RSA-2048. You have not yet begun post-quantum migration.

At 10:15, your CISO receives a call from a major client’s Chief Risk Officer asking whether your systems are protected against quantum attack and requesting written assurance within 48 hours.

Discussion questions:

1. What is our immediate containment posture? Which systems should we prioritise for emergency action, and what does “emergency action” look like when the vulnerability is in the cryptographic primitive itself?

2. Do we have an inventory of every certificate, key, and cryptographic protocol in our estate? If not, how long would it take to produce one under crisis conditions?

3. Our TLS certificates use ECDSA. Can we reissue certificates using a quantum-resistant algorithm within 48 hours? What dependencies would block this?

4. The client’s CRO wants written assurance. What can we honestly say? What cannot we say?

5. Our code-signing keys use ECDSA. If an adversary can forge signatures, what is our exposure for software already distributed to customers?

6. What would we have done differently if we had started a PQC migration programme 18 months ago?

What to Tell Your Board

A board-ready slide summarising this briefing is available as a separate PPTX file for inclusion in your next risk committee deck.

Board-Ready Slide [.pptx]

Recent research has sharply reduced the estimated computing resources needed to break the encryption that protects most of our digital infrastructure. Multiple independent research teams have published results in the first four months of 2026 showing that the quantum computers required are far smaller than previously assumed: roughly one-tenth the size estimated just two years ago. A quantum computer capable of breaking current encryption does not exist today, but the path to building one is shorter than we previously understood.

For our organisation, this means three things.

First, we need to know what cryptography we use and where. We are commissioning a cryptographic inventory across our technology estate to identify every system that depends on the algorithms that quantum computers will eventually compromise. This inventory is the prerequisite for any migration and should be completed within the current quarter.

Second, we need a migration plan. NIST has published post-quantum cryptographic standards and set deprecation deadlines: quantum-vulnerable algorithms will be deprecated for federal systems by 2030 and disallowed by 2035. The European Commission’s roadmap targets critical infrastructure migration by end of 2030. The UK NCSC expects high-priority systems migrated by 2031. We need a phased migration programme with board-level sponsorship, a designated owner, and a timeline. We will present a proposed programme structure at the next risk committee meeting.

Third, there is a current risk that requires attention now. Adversaries, state intelligence services in particular, are collecting encrypted data today with the intention of decrypting it once quantum capability arrives. If our organisation holds data whose confidentiality extends beyond 2035 (and most of our sensitive data does), we should prioritise protecting those data flows first.

This is not a crisis. It is a long-duration infrastructure programme comparable in scope to the Y2K remediation or the migration from SHA-1 to SHA-2, which took the industry over twelve years. The difference is that we now have clear standards, concrete deadlines, and a narrowing window. We recommend the board endorse the establishment of a PQC migration programme this quarter, with a first progress report at the Q3 risk committee meeting.

Indicator Watch

Stratsec is tracking the emergence of commercial PQC compliance verification services and the speed at which major cloud providers operationalise NIST PQC standards in production. Google and Cloudflare have both set 2029 as their internal PQC migration deadlines; Cloudflare reports that over 65% of human-initiated traffic on its edge already uses post-quantum encryption.[10] The rate at which enterprise software, hardware vendors, and certificate authorities follow will determine whether the 2030 deprecation timeline is achievable for most organisations or whether it becomes a compliance cliff.

We are also monitoring the acceleration of experimental quantum attacks on elliptic curve cryptography. The Project Eleven demonstration (15-bit ECC key broken on public hardware in April 2026, up from 6-bit in September 2025) provides a measurable benchmark of hardware progress.[8] While the gap to 256-bit cryptographic relevance remains immense, the trajectory bears watching.

Separately, we are monitoring for classified or TLP-restricted government advisories that may indicate a revision in official threat timelines. Any acceleration in government advisory language, from “prepare” to “act now,” would be a leading indicator that intelligence community assessments have shifted.

References

[1] C. Gidney, “How to Factor 2048 Bit RSA Integers in 8 Hours Using 20 Million Noisy Qubits” (May 2025), arXiv:2103.06159. https://arxiv.org/abs/2505.15917

[2] C. Chevignard, P-A. Fouque, A. Schrottenloher, “Reducing Quantum Factoring to Modular Exponentiation Through Quantum Fast Residue Multiplication,” CRYPTO 2025. https://eprint.iacr.org/2024/222

[3] C. Chevignard, P-A. Fouque, A. Schrottenloher, “Quantum Cryptanalysis of Elliptic Curves: Improved Circuits for ECDLP,” EUROCRYPT 2026. https://eprint.iacr.org/2026/280

[4] Google Quantum AI, “Securing Elliptic Curve Cryptocurrencies against Quantum Vulnerabilities: Resource Estimates and Mitigations,” 31 March 2026. https://quantumai.google/static/site-assets/downloads/cryptocurrency-whitepaper.pdf

[5] Oratomic, Caltech, UC Berkeley, “Compiling Shor’s Algorithm on Neutral Atom Arrays,” 31 March 2026, arXiv preprint. Analysis: https://postquantum.com/security-pqc/10000-qubits-shors/

[6] IonQ, “Fault-Tolerant Quantum Computing with Trapped Ions: The Walking Cat Architecture,” arXiv:2604.19481, 21 April 2026. https://arxiv.org/abs/2604.19481 — Analysis: https://postquantum.com/quantum-research/ionq-walking-cat-trapped-ion-ftqc/

[7] Coinbase Independent Advisory Board on Quantum Computing and Blockchain, “Quantum Computing and Blockchain” (position paper), 21 April 2026. Authors: S. Aaronson, D. Boneh, J. Drake, S. Kannan, Y. Lindell, D. Malkhi. https://www.coinbase.com/blog/coinbase-quantum-advisory-council-publishes-position-paper-on-quantum-computing-and-blockchain — Analysis: https://postquantum.com/security-pqc/coinbase-quantum-blockchain-paper-analysis/

[8] Project Eleven / G. Lelli, 15-bit ECC key broken on public quantum hardware, 24 April 2026. https://intellectia.ai/blog/bitcoin-quantum-threat-2026

[9] S. Aaronson, “Will you heed my warnings NOW?”, Shtetl-Optimized (blog), 29 April 2026. https://scottaaronson.blog/?p=9718

[10] Cloudflare, “Post-Quantum Roadmap,” 30 April 2026. https://blog.cloudflare.com/post-quantum-roadmap/

[11] NIST Interagency Report 8547, “Transition to Post-Quantum Cryptography Standards,” Initial Public Draft, November 2024. https://csrc.nist.gov/pubs/ir/8547/ipd — Analysis: https://postquantum.com/security-pqc/nist-ir-8547-ipd/

[12] NSA, “Commercial National Security Algorithm Suite 2.0 (CNSA 2.0),” September 2022, updated through 2025. https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/0/CSI_CNSA_2.0_FAQ_.PDF

[13] UK NCSC, “Timelines for Migration to Post-Quantum Cryptography,” March 2025. Three-phase timeline: 2028 discovery, 2031 high-priority migration, 2035 full migration. https://www.ncsc.gov.uk/guidance/pqc-migration-timelines

[14] European Commission / NIS Cooperation Group, “A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography,” 11 June 2025. Milestones: Member State transition begins end of 2026; critical infrastructure migration targeted by end of 2030. https://digital-strategy.ec.europa.eu/en/library/coordinated-implementation-roadmap-transition-post-quantum-cryptography

[15] Australian Signals Directorate (ASD), ISM guidance on post-quantum cryptography, 2024, recommending elimination of classical public-key cryptography by 2030. https://www.cyber.gov.au/resources-business-and-government/essential-cyber-security/ism

[16] NIST, FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA), finalised August 2024. HQC selected March 2025. https://csrc.nist.gov/projects/post-quantum-cryptography

[17] Current record for Shor’s algorithm factorisation on quantum hardware: 21 = 3 × 7 (2012). See: https://postquantum.com/post-quantum/quantum-computer-factored-question/

[18] CRQC Quantum Capability Framework, PostQuantum.com: https://postquantum.com/post-quantum/crqc-quantum-capability-framework/

[19] Global Risk Institute / evolutionQ, “Quantum Threat Timeline Report,” 7th edition, January 2025, M. Mosca and M. Piani. https://globalriskinstitute.org/publication/2024-quantum-threat-timeline-report/

[20] Harvest Now, Decrypt Later: https://postquantum.com/post-quantum/harvest-now-decrypt-later-hndl/

[21] Trust Now, Forge Later: https://postquantum.com/post-quantum/trust-now-forge-later/

[22] Google Security Blog, September 2024 (ML-KEM in Chrome); Apple PQ3 protocol, 2024.

[23] ENISA, ECCG Cryptographic Mechanisms Report v2.0, 2025. https://www.enisa.europa.eu/publications/post-quantum-cryptography-integration-study — See also ETSI TS 103 744 on quantum-safe cryptography.

Stratsec: Emerging technology threats, without the hype.

The Development

On 7 April 2026, the FBI, CISA, NSA, EPA, Department of Energy, and US Cyber Command issued a joint advisory (AA26-097A) confirming that Iranian-affiliated advanced persistent threat actors are actively exploiting internet-facing programmable logic controllers across US critical infrastructure.[1] The advisory identified disruptions in the Government Services, Water and Wastewater Systems, and Energy sectors, with some victims experiencing operational disruption and financial loss.[1]

The attackers used overseas IP addresses and leased third-party hosting infrastructure to connect to internet-exposed Rockwell Automation/Allen-Bradley PLCs, including CompactLogix and Micro850 controllers.[1] They used Rockwell’s own Studio 5000 Logix Designer software to establish connections, extracted and modified project files containing ladder logic and configuration settings, manipulated data displayed on human-machine interface and SCADA systems, and deployed Dropbear SSH on victim endpoints for persistent access via port 22.[1] Malicious traffic was observed on ports 44818, 2222, 102, 22, and 502, with patterns suggesting interest in Siemens S7 PLCs as well.[1]

The advisory links this campaign to the CyberAv3ngers group, affiliated with Iran’s Islamic Revolutionary Guard Corps Cyber-Electronic Command (IRGC-CEC), also tracked as Shahid Kaveh Group, Storm-0784, Hydro Kitten, Bauxite, and UNC5691.[1] The same ecosystem compromised at least 75 Unitronics PLC devices across US water and wastewater systems during a similar campaign beginning in November 2023.[1][2] That earlier campaign relied on factory default passwords. The current campaign exploits CVE-2021-22681, an authentication bypass vulnerability in Rockwell Logix controllers for which no vendor patch exists; only defence-in-depth mitigations are available.[1][3]

The escalation coincides with the US-Israeli military campaign against Iran that began on 28 February 2026 (Operation Epic Fury).[4] Strikes targeted Iranian nuclear facilities, military infrastructure, and senior leadership, including Supreme Leader Ali Khamenei.[4][5] Iran experienced a near-total domestic internet blackout shortly after, and a conditional ceasefire was declared on 8 April.[4] The UK’s National Cyber Security Centre issued an advisory on 2 March 2026 warning UK organisations of a heightened risk of indirect cyber threats, particularly for those with supply chains or operations in the Middle East.[6] The NCSC assessed that Iranian state and Iran-linked cyber actors “almost certainly currently maintain at least some capability to conduct cyber activity” despite the blackout.[6]

The broader Iranian cyber ecosystem has activated in parallel. Tenable reports that CyberAv3ngers’ ICS exploitation techniques have proliferated to an estimated 60 or more pro-Iranian hacktivist groups.[3] Handala, a group widely assessed to operate under Iranian intelligence protection, claimed a destructive attack against US medical technology firm Stryker in March 2026, asserting it wiped approximately 200,000 devices via a compromised Microsoft Intune environment; Stryker confirmed severe operational disruption, though the scale figures have not been independently verified.[7] MuddyWater was observed conducting coordinated intrusions against a US bank, an airport, NGOs, and an Israeli-linked defence supplier in late February, using newly built backdoors and cloud-based data exfiltration.[7] The Center for Strategic and International Studies published analysis in April characterising Iran’s cyber posture as a shift from episodic attacks to a sustained campaign treating cyberspace as an extension of state power.[8]

US financial regulators have also responded. FINRA issued a cybersecurity alert warning member firms of heightened risks from Iranian state-sponsored and aligned actors, specifically citing the exploitation of known vulnerabilities, default credentials, and brute-force techniques.[9]

In future issues, the following sections (Reality Check, Action Brief, CISO Governance Briefing, and Board Brief) will be available exclusively to paid subscribers. This issue is published in full so you can experience the complete Stratsec intelligence product.

The Reality Check

Assessment: Significant. This is a genuine escalation in Iranian intent to cause disruptive effects on Western critical infrastructure. It is not a novel capability or an insurmountable technical challenge.

The core issue is basic: exposed industrial control systems are being compromised through poor hygiene. In every documented case, the attackers are scanning the public internet for PLCs protected by default passwords, unpatched authentication bypasses, or no access controls at all. They are connecting using the manufacturer’s own legitimate engineering software. The sophistication is in the targeting and the intent, not in the technique.

Two things have changed since the 2023 Unitronics campaign. First, the attacks are causing confirmed operational disruption and financial loss. The 2023 campaign was largely symbolic: screens displaying political messages, limited real-world impact. The April 2026 advisory documents actual manipulation of control logic and process displays, with victims reporting genuine operational consequences.[1] Second, the geopolitical context has elevated the threat tempo. The February 2026 military campaign against Iran triggered the largest single-event activation of Iranian-aligned cyber actors ever documented, according to threat intelligence firms.[7] With conventional military options constrained, cyber operations against US and allied infrastructure become a more attractive asymmetric response for Tehran.[8]

Three realities temper the alarm.

First, the technical barrier remains low. These attacks work because defenders have not implemented measures that have been recommended for years: remove OT from the public internet, change default passwords, segment networks, enforce authentication. Organisations that have already done this are far less attractive targets. The NCSC’s assessment is instructive: there is no significant change in the direct cyber threat to the UK, but the risk of indirect effects and opportunistic exploitation has increased.[6]

Second, the Iranian cyber apparatus has been degraded by the conflict. The 2026 ODNI Annual Threat Assessment assessed that Iran’s ability to conduct and defend against cyber operations was constrained by the 2025 war and subsequent military pressure.[10] The IRGC command structure has been significantly weakened. The domestic internet blackout limits coordination. But degraded is not neutralised. The proxy ecosystem, cultivated over a decade, now operates with greater autonomy. CyberAv3ngers’ techniques have spread to dozens of affiliated groups.[3] The threat has become more distributed, less predictable, and in some ways harder to defend against because there is no single adversary with a single playbook.

Third, geographic distance offers no protection. Iranian-affiliated groups scan globally for exposed OT devices. Any organisation running internet-connected industrial control systems is a potential target, regardless of sector or location. European organisations fall under additional pressure via NIS2 obligations to manage emerging threats proportionately. The UK NCSC’s advisory and FINRA’s alert both confirm that allied nations and financial regulators treat this as requiring organisational action now.[6][9]

The central message: the nature of the Iranian cyber threat to Western critical infrastructure has not changed. What has changed is the operational tempo, the willingness to cause real disruption, and the number of actors involved. Defenders retain a structural advantage, but only if they treat internet-exposed OT as the urgent hygiene failure it is.

The Action Brief

Remove OT devices from the public internet. If a PLC, HMI, RTU, or SCADA component does not require public internet connectivity to perform its function, disconnect it. If remote access is operationally necessary, place it behind a secure gateway or VPN with phishing-resistant multifactor authentication. Conduct an external scan this week to verify no OT devices are directly reachable. This is the single most effective action you can take.

Inventory your Rockwell Automation Logix controllers. CyberAv3ngers are actively exploiting CVE-2021-22681, for which there is no vendor patch. Implement Rockwell’s recommended mitigations: network segmentation isolating engineering workstations from untrusted networks, strict access controls, and continuous monitoring for unauthorised engineering sessions. Ensure physical mode switches on applicable controllers are locked in the run position to prevent remote logic modifications.

Audit third-party and vendor remote access. The Stryker compromise and the advisory’s own TTPs confirm that trusted third-party pathways remain a primary attack vector. Review every vendor maintenance gateway, remote support portal, and contractor access account touching your OT environment. Remove anything that cannot be justified. Enforce MFA on everything that remains. Enable logging.

Search your network logs for the advisory’s indicators. Direct your SOC to query firewall and IDS logs for inbound connections to ports 44818, 2222, 102, 22, and 502 from overseas hosting providers. Look for the IP addresses listed in the CISA STIX package (AA26-097A). Check for unauthorised Dropbear SSH installations and unexpected modifications to Rockwell project files (.ACD, .L5X).

Test offline backups of PLC logic and configurations. If an attacker manipulates your control logic, your recovery speed depends on having verified, offline backups of PLC programmes, HMI configurations, and historian data. Test restorability now, before you need it.

CISO Governance Briefing

Enterprise Risk Management

This development does not create a new risk category. It changes the likelihood and velocity parameters for OT compromise scenarios that should already be in your risk register.

Update the likelihood rating for exploitation of internet-facing OT devices. Where previous assessments assumed that ICS targeting by state actors was rare, opportunistic at most, and focused primarily on geographically proximate adversaries, the evidence now shows sustained, globally scoped campaigns causing confirmed operational damage.[1] For organisations running internet-exposed PLCs, HMIs, or SCADA components in water, energy, government services, or manufacturing, move the likelihood assessment up by at least one tier.

If you use a quantitative model, revisit the time-to-exploit assumption. The advisory documents connection and manipulation within hours of device discovery. If you use a qualitative model, the relevant shift is from “possible” to “likely” for any externally facing OT system without gateway-mediated access controls.

Budget and Resourcing

This does not require a large new technology investment for most organisations. The primary spend implications are in process discipline and targeted hardening of existing OT environments.

Reallocate resources from deferred OT segmentation projects. If your organisation lacks dedicated OT visibility or monitoring capability, budget for one to two targeted hires or external support to accelerate network segmentation and logging improvements over the next two quarters. The tools are largely available; the gap in most organisations is adoption.

For organisations with legacy OT where patching is impractical (and CVE-2021-22681 has no patch), compensating controls are capital investments: hardware-enforced unidirectional gateways at IT/OT boundaries, managed switches with documented access control lists, and independent monitoring of OT traffic. If these investments have been deferred, the case for acceleration is now stronger.

Policy and Procedure Updates

Review and update four areas.

Network architecture and remote access: explicitly prohibit direct internet exposure of OT devices. Mandate gateway-mediated access with MFA for all remote OT connections.

Vulnerability and asset management: include all internet-facing OT devices in scanning and patching cycles. Where patching is impractical, document approved compensating controls and review them quarterly.

Incident response: incorporate OT-specific playbooks for PLC manipulation and HMI data alteration scenarios, including rapid isolation procedures, offline restoration from backups, and coordination with OT engineering teams. The window between initial access and operational disruption may be hours, not days.

Third-party risk management: extend supplier assurance to cover OT security controls explicitly (see Supplier Assurance Questions below).

Regulatory Exposure

NIS2 and DORA require boards to oversee proportionate management of emerging threats. Regulators increasingly view unmitigated internet exposure of critical control systems as evidence of inadequate risk management. The April 2026 CISA advisory, combined with the UK NCSC guidance, provides contemporary benchmarks against which post-incident regulatory scrutiny will be judged.[1][6]

No regulator has formally changed its expectations. But the practical defensibility of a 90-day patching cycle for an internet-exposed PLC has weakened considerably when six government agencies are jointly warning of active exploitation causing financial loss. European organisations subject to NIS2’s board-level accountability provisions (with fines of up to 2% of global turnover) should document their board’s awareness and the specific hardening actions taken. FINRA’s alert to financial services firms signals that sector regulators are watching this space closely.[9]

Team Skills

The capability gap this exposes is at the IT/OT boundary. Your security team needs people who can identify and secure internet-exposed industrial devices, configure secure remote access gateways, interpret vendor-specific logs (Rockwell Studio 5000 activity, for example), and distinguish legitimate engineering traffic from anomalous lateral movement.

Most organisations already have the necessary personnel. What they lack is focused training and clear policy direction. Prioritise upskilling in OT network segmentation and basic ICS protocol monitoring over the next 12 months. Cross-train process control engineers in security fundamentals and security analysts in OT basics.

Second-Line and Third-Line Oversight

Risk management (second line) should verify that OT exposure has been mapped and remediated across the estate, and that risk register updates reflect current threat velocity and the demonstrated Iranian willingness to act against exposed devices.

Internal audit (third line) should include internet-exposed OT devices and remote access controls in its next cyber risk review scope. The audit should verify that the organisation maintains a current inventory of internet-facing OT assets and that compensating controls for unpatchable vulnerabilities are documented and tested.

Supplier Assurance Questions

Send these to critical OT/ICS technology suppliers, system integrators, and remote-service providers this quarter.

1. Are any of the PLCs, HMIs, or SCADA components you supply or support configured for direct internet access? If yes, what controls prevent unauthorised programming or data manipulation?

2. What is your process for ensuring programming protection, mode-switch settings, and offline backup capabilities are enabled by default or during deployment?

3. Do you use or recommend secure gateway/jump-host architectures for any remote access to our OT environments? How is MFA enforced at the network layer?

4. Have you reviewed the April 2026 CISA/FBI advisory (AA26-097A) for applicability to the equipment and services you provide to us?

5. What monitoring and logging do you maintain for vendor software (e.g., Studio 5000) access to our systems?

6. In the event of detected manipulation of project files or HMI data, what is your compressed notification and restoration support timeline?

7. Do your contracts include liability provisions for breaches originating from internet-exposed OT devices or remote-access pathways you manage?

Team Readiness Checklist

Use these questions with your OT/security leadership team:

OT exposure and segmentation

• Have we identified and documented every internet-facing PLC, HMI, or SCADA component across the estate?

• Which devices remain directly reachable from the internet, and what is the plan to remove them?

• Is the boundary between corporate IT and OT governed by strict, hardware-enforced segmentation?

Remote access controls

• Are all remote OT connections mediated through MFA-enforced gateways rather than direct exposure?

• Have we audited third-party and vendor remote-access privileges in the last 90 days?

• Have cellular modems and other remote field devices been secured and logged?

Backup and recovery

• Do we have tested, offline backups of all critical PLC logic and configurations?

• Can we restore a manipulated PLC within operational recovery time objectives?

Monitoring

• Are we logging and alerting on anomalous vendor software connections, unexpected OT port activity, or project file changes?

• Has our SOC ingested the IOCs from CISA advisory AA26-097A?

Incident response

• Has the IR team rehearsed an OT manipulation scenario involving HMI/SCADA data alteration?

• Can we execute containment actions (network isolation, mode-switch lockdown, credential rotation) within one hour of detection?

Second-Line and Third-Line Assurance Questions

For risk management (second line):

• Has the first-line team mapped all internet-exposed OT devices and implemented compensating controls or removal?

• Have risk register entries for OT compromise been updated to reflect current Iranian TTPs and threat velocity?

• Is there evidence of MFA-enforced gateway access for all remote OT pathways?

• Has the incident response playbook been tested against an OT manipulation scenario in the last 90 days?

For internal audit (third line):

• Does the organisation maintain a current inventory of internet-facing OT assets, and have exposure risks been addressed?

• Are there documented, tested procedures for rapid PLC restoration following manipulation?

• Has the supplier assurance programme been extended to cover OT/ICS security controls?

• Is the board receiving accurate, timely reporting on geopolitically driven cyber threats to OT environments?

Tabletop Exercise: OT Manipulation Scenario

Hand this scenario to your incident response team. It requires no additional preparation. Allow 90 minutes.

Scenario:

It is 08:30 on a Wednesday. Your water treatment plant’s SCADA system begins displaying anomalous readings on several HMI screens. Operators report that set points for chemical dosing appear to have been altered remotely. Initial triage confirms unauthorised access to a CompactLogix PLC via an unexpected external IP address using Rockwell programming software. The system remains operational but critical process parameters are changing. Plant safety systems have not yet triggered, but the window for safe containment is narrowing.

At 09:15, the incident response team discovers that the attackers used credentials belonging to a trusted third-party maintenance contractor. The contractor’s access was not enrolled in multifactor authentication. The attackers are actively modifying ladder logic on a second controller responsible for pressure regulation.

Discussion questions:

1. What is our immediate containment action, and can we execute it within 15 minutes of detection?

2. Who in the organisation has the authority to physically isolate the OT network, and are they available now?

3. How do we restore the manipulated controllers from offline backups while maintaining partial manual operations?

4. The same third-party contractor has access to four other sites in our estate. How do we check and protect those systems while responding to the active compromise?

5. Under NIS2, what are our immediate regulatory notification obligations and timeline? Who needs to be notified internally within the first hour?

6. What post-incident changes to remote access policy and network segmentation are non-negotiable?

What to Tell Your Board

A board-ready slide summarising this briefing is available as a separate PPTX file for inclusion in your next risk committee deck.

Board-Ready Slide [.pptx]

Iranian-affiliated cyber actors are actively targeting internet-connected industrial control systems in Western critical infrastructure. US government agencies have confirmed that these attacks have caused operational disruptions and financial losses at water, energy, and government facilities. The attackers are exploiting basic security weaknesses in systems that should never have been connected to the public internet.

For our organisation, this means three things.

First, any remaining internet exposure of our operational technology must be eliminated or tightly controlled. We are conducting an emergency audit to verify that no industrial control systems are directly reachable from the internet, and are reviewing and hardening all remote-access pathways and PLC configurations this quarter.

Second, our OT environments require the same disciplined segmentation and monitoring long applied to corporate IT networks. We are accelerating existing segmentation projects and ensuring offline backups of critical control system logic are in place and tested.

Third, we are extending our supplier assurance and third-party risk processes to cover OT/ICS security controls explicitly. A breach through a supplier’s remote access now moves at machine speed.

This is not a new threat category, but it is a clear demonstration that previously tolerable exposures are now actively exploited. The appropriate response is to close long-standing gaps in our OT security posture. We recommend the board receive a detailed OT exposure assessment and remediation plan at the next risk committee meeting, with implementation targeted for completion before end of Q3 2026.

Indicator Watch

Stratsec is tracking the potential proliferation of PLC exploitation techniques beyond Rockwell and Unitronics devices to other common industrial control system vendors. The April 2026 advisory explicitly notes actors probing ports associated with Siemens S7 protocols, and the pattern of scanning activity suggests interest in any internet-exposed industrial controller regardless of manufacturer.[1]

We are also monitoring for increased targeting of European CNI operators via supply-chain pathways or indirect spillover effects, consistent with UK NCSC guidance on heightened regional risk.[6] If exploitation tools and techniques continue to spread across the 60-plus affiliated hacktivist groups identified by threat intelligence firms, the volume of opportunistic attacks against exposed industrial control systems will increase over the next two quarters.[3]

References

[1] FBI, CISA, NSA, EPA, DOE, and CNMF, “Iranian-Affiliated Cyber Actors Exploit Programmable Logic Controllers Across US Critical Infrastructure,” AA26-097A, 7 April 2026. https://www.cisa.gov/news-events/cybersecurity-advisories/aa26-097a

[2] CISA, “IRGC-Affiliated Cyber Actors Exploit PLCs in Multiple Sectors, Including US Water and Wastewater Systems Facilities,” AA23-335A, updated December 2024. https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-335a

[3] Tenable, “CyberAv3ngers: FAQ About Iran-Linked Threat Group Targeting U.S. Critical Infrastructure,” April 2026. https://www.tenable.com/blog/what-to-know-about-cyberav3ngers-the-irgc-linked-group-targeting-critical-infrastructure

[4] House of Commons Library, “Israel/US-Iran conflict 2026: Background and UK response,” Research Briefing CBP-10521, updated April 2026. https://commonslibrary.parliament.uk/research-briefings/cbp-10521/

[5] The Record, “British organizations urged to be alert to threat of Iranian cyberattacks,” 2 March 2026. https://therecord.media/iran-britain-cyber-threats-warning

[6] UK NCSC, “NCSC advises UK organisations to take action following conflict in the Middle East,” 2 March 2026. https://www.ncsc.gov.uk/news/ncsc-advises-uk-organisations-take-action-following-conflict-in-middle-east

[7] Sapphire, “What the 2026 Iran Conflict Means for UK Cyber Risk,” March 2026. https://www.sapphire.net/blogs-press-releases/what-the-2026-iran-conflict-means-for-uk-cyber-risk/

[8] Center for Strategic and International Studies, “The Iranian Cyber Threat to U.S. Critical Infrastructure,” April 2026. https://www.csis.org/analysis/iranian-cyber-threat-us-critical-infrastructure

[9] FINRA, “Cybersecurity Alert: Heightened Threats From Iranian Cyber Actors,” March 2026. https://www.finra.org/rules-guidance/guidance/cybersecurity-alert-heightened-threats-iranian-cyber-actors

[10] Office of the Director of National Intelligence, “2026 Annual Threat Assessment of the U.S. Intelligence Community,” 2026. Referenced in CSIS analysis.

Stratsec: Emerging technology threats, without the hype.

Most of it is noise. Some of it isn’t. The problem is telling which is which.

That’s what Stratsec does.

The problem we solve

The information landscape for emerging technology threats is broken. Vendor-funded research exists to sell products. Media coverage optimises for clicks, not accuracy. Analyst reports arrive months after you needed them. And government advisories, the ones that used to be reliable, are getting thinner as agencies lose headcount and budgets.

Meanwhile, NIS2, DORA, and the EU AI Act are creating board-level accountability for emerging technology risk. Directors have a regulatory obligation to oversee threats they don’t yet have frameworks to assess.

CISOs and security leaders need a source they can trust. One that tells them what’s real, what’s overblown, and what to actually do about it.

What we publish

The Stratsec Emerging Threat Monitor is a regular intelligence briefing covering emerging technology developments with security and risk implications. Each issue covers developments across five threat domains:

• AI Security & Governance: what new AI capabilities actually mean for your security posture

• Quantum Security: real timelines versus media hype, PQC migration priorities

• Robotics, Drones & Autonomous Systems: cyber-physical attack surfaces that are expanding faster than the frameworks to manage them

• Tech-Geopolitics: how semiconductor politics, export controls, and state-sponsored competition affect your technology decisions

• Regulatory Horizon: NIS2, DORA, EU AI Act, and what’s coming next

Issues take one of two formats. Multi-item issues cover four to five developments across the domains. Single-topic deep dives give one major development the comprehensive treatment it warrants: full narrative, governance analysis, and a complete operational toolkit.

Every item follows a three-part structure:

The Development: what actually happened, in plain language, without hype. (Free for all subscribers.)

The Reality Check: is this a genuine shift or incremental? Should you brief your board or file it for later? The honest assessment a trusted peer would give you over coffee. (Paid subscribers.)

The Action Brief: what to do, practically. Not “assess your risk posture,” but concrete steps for this week. (Paid subscribers.)

Readable in ten minutes. Dense with insight, zero filler.

Who we are

Stratsec is not a vendor, a media outlet, or a think tank. We are practitioners.

Our team and advisory circle includes former Fortune 500 CISOs and CROs, global cybersecurity practice leaders from the Big Four and major systems integrators, founders of what was at the time the world’s largest offensive security firm, heads of national cybersecurity organisations, intelligence professionals from NATO-aligned nations, and current leaders in quantum security and AI risk.

When we say “double down on hygiene,” it’s because people who’ve run programmes at scale know that’s usually the right answer. When we say “this is genuinely new,” it’s because people who’ve seen decades of threats know when something is different.

What you get

Free subscribers receive The Development section of every item: a properly contextualised, hype-free summary of what happened. Better than what most people get from tech media.

Paid subscribers receive the full intelligence product:

The Reality Check and Action Brief for every item: whether it matters and what to do about it.

The CISO Governance Briefing: how to register this in your risk framework, what it means for your budget, which policies need revision, where your regulatory exposure has shifted, what skills your team needs, and what your second and third-line functions should be checking.

What to Tell Your Board: board-ready language you can use verbatim or adapt for your next risk committee meeting, with a companion slide in Stratsec brand you can drop directly into your deck.

The CISO Toolkit: supplier assurance questions you can send to your critical vendors this week, a team readiness checklist to surface gaps before they become incidents, assurance questions for risk management and internal audit, and a tabletop exercise scenario your incident response team can run without preparation.

Indicator Watch: one pre-threat signal Stratsec is monitoring before it becomes a headline.

Full archive access to every issue.

Subscribe

The first full issue is in production now. Subscribe to make sure you don’t miss it.

Emerging technology threats, without the hype.