When AI Finds Faster Than Your Patch Cycle: What KRITIS Platforms Must Change Now

02:47 AM, data center of a German utility provider. The alert did not come through the SIEM. It arrived by email from a coordinated disclosure: a remotely exploitable vulnerability in a component that has been running in production for fourteen years, found by an autonomous model in a single overnight session. The platform lead reads the CVE number, opens the asset inventory and searches for dependencies. He finds 214 systems. His patch window is three weeks.

This scenario is not dystopia. It is the new normal in the so-called Mythos era, a shift in attack velocity that Anthropic made visible with the announcement of its unreleased frontier model Claude Mythos and the parallel defensive program Project Glasswing. What quarterly pentests used to cover is increasingly processed in hours, just not necessarily by defenders.

For platform owners in CRITIS operators, financial institutions and energy providers, this is not an academic debate. It is a regulatory, operational and personal liability question. And the discussion currently unfolding in trade media and on platforms like Medium follows a striking pattern: it describes the problem with growing urgency while omitting the answer.

What Everyone Says, and What No One Says

Reviewing the public discussion on Medium in April 2026 yields roughly 15 serious articles on the topic. The authors are tech journalists, AI analysts, former engineers at major platforms. The texts are worth reading. But they share a pattern.

• “What is Claude Mythos?” - Explanation of the model, its benchmarks, its partner list.
• “AI So Powerful Anthropic Won’t Release It” - Dramaturgy of restraint.
• “The Dawn of AI Hackers” - Epistemic framing of the new attacker class.
• “AI That Finds Bugs Humans Missed” - Fascination with what was found.

None of the reviewed articles address the question that a platform owner in a regulated operation actually asks at three in the morning: What do I do operationally before the alert arrives? The texts offer diagnosis, little practice, principles or sequence of action.

That is understandable. Fascination sells better than operations. But it is irrelevant to your situation. If you advise the executive board of an organization subject to NIS2 compliance, you do not need another description of the threat. You need a plan that holds up in an audit.

Observation: The debate reproduces the problem instead of solving it. Anyone searching as a CRITIS officer for an operational answer finds almost exclusively problem rhetoric on the open web. That is the actual news value of this article.

The New Reality in Hard Numbers

Before we get to the answer, the threat landscape must be put on the table, soberly and without dramaturgy. All following figures are documented by the primary source anthropic.com/glasswing.

Metric	Value
Firefox exploits in a single run	181
Factor vs. predecessor (2 exploits)	90x
Previously unknown zero-days	14
Glasswing partners	~50

The 181 Firefox exploits are the real turning point. In a single autonomous run, Claude Mythos found 90 times more vulnerabilities than its predecessor, including 14 previously unknown zero-days. Autonomous exploit development from vulnerability discovery to working proof-of-concept without human rework. Performance at the level of highly qualified software engineers when analyzing attack paths across distributed systems.

More important than the number is the conclusion: the assumption that an attacker needs weeks or months for reconnaissance, discovery and exploit development no longer holds. According to Gartner projections, comparable models from competitors (OpenAI, Google DeepMind, Meta, Chinese labs) will reach Mythos-level capabilities within 6 to 18 months.

The economic model of security pipelines is changing structurally. What previously required significant human effort - vulnerability research, exploit development, chain building - becomes parallelizable, accelerated and more cost-effective through Mythos-class models. The attacker side gains a structural lever that defenders using current methods will find increasingly difficult to compensate.

What NIS2 and the CRITIS Act Now Concretely Require

The regulatory landscape in DACH has tightened in parallel with the technical threat landscape, in a way that both sides reinforce each other.

NIS2UmsuCG has been in force since December 2025. It requires affected organizations - and after the expansion, significantly more than under the old NIS directive - to maintain continuous vulnerability monitoring, documented vulnerability processes, evidence of attack detection, and reliable reporting channels. Executive management is responsible for implementation and can be held personally liable for breaches. Fines reach up to 10 million euros or 2 percent of global annual revenue, whichever is higher.

The CRITIS Act was passed by the Bundesrat on March 6, 2026. It extends resilience obligations both physically and digitally, mandates an audit every three years and interlocks the evidence obligation with the NIS2 process. What both regulations demand is not a state, but a continuously documented process with evidence.

Audit reality: An auditor does not ask whether you hardened. They ask which hardening was active at which date, who approved it, what drift occurred in between, and what evidence you can present. If this trail is missing, the finding is documented. And the exposure window between finding and potential exploitation grows shorter in the Mythos era, regardless of audit schedules.

This means operationally: an Excel sheet with hardening measures maintained once per quarter generally does not meet the evidence requirements. A manual CIS benchmark review once a year even less so. What auditors expect in the Mythos era is an automated, versioned, auditable chain from requirement to state.

Why Traditional Hardening No Longer Suffices

Most enterprise platforms are optimized for a world that no longer exists. The pattern is familiar: inventory, gap analysis, measure catalog, JIRA ticket, approval process, change window, pentest. Between discovery and remediation, realistically, three to ten weeks pass. In well-organized organizations. In poorly organized ones, significantly more.

In the Mythos era, this window meets a new speed class on the attack side. The result is not that your platform falls immediately. The result is structural: the probability that no countermeasure is active at the time of a vulnerability shifts measurably against you.

The Problem Is Not “Mythos” - It Is the Cycle

If your platform hardening is not set up as a continuous, automated, auditable process, the question is no longer whether you have a vulnerability. The question is how many days lie between the public availability of a similar model and your next change window.

This applies especially to platforms with long lifecycle dependencies: JBoss EAP, older Linux LTS distributions, Windows Server behind specialized applications, IIS for classic .NET stacks, Tomcat, on-premises and cloud Kubernetes clusters. Where “just redeploy” is not an option, responsiveness does not count. What counts is prevention as a process.

The Operations Answer: Platform Hardening as a Continuous Process

What NIS2, the CRITIS Act and the Mythos era together demand is not new software. It is a restructuring of how work is done, away from projects, toward operations. The principles are neither revolutionary nor new. They are known from other domains: infrastructure-as-code, GitOps, observability. What is new is that they become mandatory for platform security.

Seven core capabilities against which the operating model must measure itself, in two clearly separated layers: an operational foundation of four capabilities, on which three more build.

The Foundation: Four Capabilities That Carry the Impact Path

Policy, Golden Image, Automated Deployment, Verification. This flow is the actual operational core. Without it, nothing happens: no evidence, no auditability, no enforcement. Only documents on file shares.

1. Security standards, baselines and policies. CIS benchmarks, NIST, customer-specific requirements and lennlay standards are versioned and stored in a standardized way, so they can reproducibly flow into golden images and baselines. This is the definition of what “secure” actually means in this environment.
2. Golden images and platform baselines. From the policy, hardened, standardized base artifacts emerge, traceable from “upstream base” to “production image.” The policy becomes an artifact that can be built, signed and versioned.
3. Automation, deployment and platform integration. The point missing from most debates: How do baselines and images actually reach the target platforms? Through Ansible collections, CI/CD pipelines, GitOps or IaC-based deployments, into servers, VMs, containers and OpenShift/Kubernetes. Without this layer, hardening remains a recommendation; only through deployment and integration into the existing toolchain does it become a reproducible state of the platform.
4. Compliance verification and reporting. The control that policies are actually implemented on all target platforms, automated, every night, not quarterly. Deviation generates a ticket and structured report, not an Excel row.

Above That: Three Capabilities for Management, Auditors and Operations

When the foundation stands, the capabilities that the supervisory board, auditor and lifecycle planning will later demand come next, and which are only reliable when the four lower layers run continuously.

5. Documentation, traceability and auditability. Every hardening action, every change, every exception generates an audit entry. Evidence is a byproduct, not a quarter-end exercise, and exactly what NIS2 auditors and internal revision want to see.
6. Lifecycle and update management. Support end dates, versions, security updates and migrations are attributes on the asset, not in a memo. When the end of support for JBoss EAP 7 approaches, the date is on the dashboard, not in the admin’s head.
7. Drift detection and enforcement. Deviation from the target state is not a side finding but a trigger, remediated in a controlled manner depending on the risk profile. Those who drift, explain.

What Concretely Changes per Core Capability

So the title does not remain abstract: the operational delta between today’s operations and what the Mythos era demands.

Core Capability	Typical Today	Required Post-Mythos
Security standards	CIS benchmarks as PDF on SharePoint. Annual manual review.	Policies versioned and stored in standardized format, reproducibly flowing into golden images.
Golden images	Vendor image plus manual hardening checklist per server.	Built, signed, versioned golden images from reproducible pipeline.
Automation	Individual playbooks, custom scripts, manual work in change windows.	Ansible collections, CI/CD, GitOps, rollout to server, VM, container, OpenShift as standard process.
Compliance verification	Quarterly pentest, external report, Excel measure list.	Nightly automated verification, structured report, deviation generates ticket.
Documentation	Audit preparation as separate effort two weeks before review.	Evidence created during operations. Audit report at the push of a button from platform data.
Lifecycle management	End-of-support arrives via memo at Ops. Update planning in the heads of a few individuals.	EOL dates as asset attribute on dashboard. Update pipeline as visible process.
Drift detection	Deviation found in the next audit, or not at all.	Drift detected and transparently evaluated. Automatic enforcement selective and controlled.

These seven core capabilities form the foundation of the Secure Platform Automation Suite (SPAS), which lennlay uses to make platforms secure, standardized, auditable and automatically operable. SPAS is not a new tool. It is the platform perspective across security scanners, SIEM, ticket systems and your existing automation - the operational layer that makes these tools audit-ready and permanently effective for the Mythos era.

Why We Start with JBoss EAP in DACH

In practice, good platform hardening does not arrive as wildfire across all systems simultaneously. It comes in campaigns, system by system, with a clear entry point where the lever is greatest. In many DACH enterprises, that is JBoss EAP.

Why JBoss First

• Concentration of business-critical applications. In banks, insurance companies and industrial enterprises, JBoss EAP often carries core applications that cannot be migrated at short notice.
• Lifecycle pressure. Red Hat has fixed end-of-support dates. If you are running EAP 7, you know what we are talking about.
• Clear compliance landscape. CIS benchmarks and DISA-STIG exist and are machine-readable. Automation can connect directly.
• High security impact per effort. A single EAP campaign often remediates triple-digit instances at once.

From consulting practice, a recurring pattern for the first step emerges: four weeks from kick-off to the first audit-ready report. Week 1: scoping and asset inventory. Week 2: module adaptation to customer reality. Week 3: pilot rollout to staging and selected production. Week 4: regular operations, drift monitoring, first evidence package.

What You Can Do This Week, Independent of Us

Regardless of whether you work with lennlay, three steps are realistic and meaningful within the next ten business days.

1. Responsibility map. Who has operational responsibility for which platform class, who maintains compliance evidence, who is authorized to execute a rollout? Especially with systems that migrate across department boundaries, this is often where the largest gap exists. Without this map, all further steps run into interface conflicts.
2. Risk prioritization by exposure. Not all platforms are equally urgent. First wave: everything that faces outward - web servers and reverse proxies at the perimeter boundary, API gateways, ingress components. Second wave: internal specialized applications with internet impact, often JBoss EAP, Tomcat, business-critical middleware. Back office comes later.
3. Evidence inventory and NIS2 mapping for top systems. For each prioritized platform: which standard is applied, when was it last verified, how automated is the verification, how quickly can an audit report be produced? The result is rarely encouraging - but it is the most honest starting point for conversations with executive management and audit.

These three steps can be done independently, or we accompany specifically the parts where things get stuck. The point where a conversation becomes obvious is usually concrete: platforms are inventoried but not hardened. CIS benchmarks exist but nobody knows how to use them to actually harden platforms reproducibly. Or JBoss EAP 7 is approaching end of support and the migration is not planned.

Frequently Asked Questions from Platform Owners

Does Mythos affect our platform at all if we do not use the model?

The question is not whether you use Mythos, but whether attackers or researchers use a comparable model. Mythos is the publicly visible tip of a category. According to Gartner projections, competitor models will reach Mythos capability level within 6 to 18 months. The defense line shifts regardless of which specific model you license.

What does NIS2 concretely require for platform hardening?

NIS2UmsuCG has been in force since December 2025. Organizations must maintain continuous vulnerability monitoring, documented vulnerability processes and evidence of attack detection. Non-compliance carries fines of up to 10 million euros or 2 percent of global annual revenue. Executive management can be held personally liable for breaches.

Is our existing vulnerability management sufficient?

The classic quarterly model has a time window of weeks to months. When an autonomous model finds zero-days in hours, a structural gap emerges. The answer is not “more pentests” but continuous, automated, audit-ready hardening as a process.

Why JBoss EAP first specifically?

In many DACH enterprises, JBoss EAP carries business-critical specialized applications. Lifecycle pressure, CIS and DISA-STIG conformity and tight coupling to core applications make it the deployment field with the highest lever. Additional platform modules follow in a clear roadmap: Linux, Windows, containers, Kubernetes.

What does a realistic first step look like?

A 15 to 30 minute platform check as an online meeting. No pitch. We clarify: which platforms are under pressure, where the compliance need for action lies, whether and how SPAS fits. Booking directly on the SPAS product page. As preparation, the architecture brief is recommended: 13 pages PDF, without marketing sequence.

---

SPAS overview: Secure Platform Automation Suite