Vulnerability management: AI forces companies to rethink

Anthropic’s Claude Mythos demonstrates vulnerability discovery at scale

The BSI’s recent warning is remarkable for a simple reason: not because vulnerabilities are anything new, but because the speed at which they can be found is changing. The starting point is the assessment that AI-supported systems could in future be capable of identifying hidden software vulnerabilities at scale. This has recently become visible through the example of Claude Mythos, a tool developed by Anthropic. In this context, the BSI has spoken of possible upheavals in how security vulnerabilities are handled and even of a paradigm shift in the cyber threat landscape. And this is precisely where the risk lies. What helps defenders will sooner or later also help attackers on a regular basis.

For companies, this shifts the focus. It is no longer enough to treat vulnerability management as a downstream IT security process somewhere between patch management, ticket queues and occasional security scans. A technical development can very quickly become an organisational problem.

The Cyber Resilience Act (CRA) affects manufacturers and other organisations responsible for products with digital elements. For them, key reporting obligations for actively exploited vulnerabilities and severe security incidents will begin as early as 11 September 2026.

The real weakness is often not in the technology

Many companies are already investing in security tools, scans and monitoring. That is right and important. But it only solves part of the problem.

The bigger weakness often lies elsewhere: in a lack of transparency about the components in use, unclear responsibilities, lengthy approval loops and processes designed for routine operations rather than time pressure. These are precisely the gaps that become dangerous when new vulnerabilities emerge more quickly and, in the worst case, can also be exploited more quickly.

At that point, the question is no longer merely whether an organisation takes security vulnerabilities seriously in principle. What matters is whether it can quickly and reliably say whether its product is affected and who internally is authorised to make immediate decisions.

What measures companies should introduce now

1. Robust vulnerability management with clear responsibilities

The most important lever is initially organisational. Companies need a fixed process that works consistently from the first vulnerability report through to the technical and communicative response. Without friction. And without spontaneous debates about responsibilities.

This includes a defined intake channel for security reports, an initial technical assessment, traceable prioritisation, a decision on whether to fix, provide a workaround or monitor, and finally coordinated internal and external communication. Particularly with a view to the CRA, it is clear that such a structure is not merely useful, but practically indispensable. Without intake, assessment, exploitability checks, fix coordination and clear communication channels, it is almost impossible to establish a clean reporting process.

2. Professionalise triage

Under time pressure, triage is not a buzzword. It is a functioning decision-making process.

Companies should define binding rules for when a mere indication is escalated internally, when an anomaly becomes a relevant vulnerability and who is responsible for classification. Particularly where deadlines are tight and threat situations are dynamic, good triage determines whether a company remains capable of acting or gets stuck in internal coordination loops.

3. Make product and component knowledge centrally available

If you do not know exactly what is inside your own product, you will probably react too late. It is as simple as that.

That is why companies need central transparency regarding versions, releases, update mechanisms, support periods and dependencies in use. This is particularly relevant for embedded systems, industrial software and complex supply chains. In these areas, it is rarely possible to answer the question of whether a product is affected within just a few minutes. The CRA addresses precisely this point and requires technical documentation covering the security architecture, risk assessment and software components used. In this context, the creation and maintenance of an SBOM is rightly increasingly understood as a central element of robust vulnerability management.

4. Set up proper reporting channels for security researchers and third parties

Anyone who does not have clear contact points, a published security contact option and a robust policy for handling vulnerability reports loses valuable time in a real incident. A functioning reporting channel is therefore not a nice-to-have, but part of basic security hygiene.

5. Accelerate update and approval processes

Identifying vulnerabilities is only half the work. The other half is actually rolling out measures.

Many organisations fail at this point because of lengthy approval loops, missing test paths or inconsistent responsibilities between development, product management, security, support and legal. Companies should therefore treat their patch and update processes as critical operational processes: with clear escalation paths, prepared templates and realistic test runs.

6. Include the supply chain

Especially in digital products, relevant risks rarely arise only from a company’s own code. Libraries, firmware components, supplier components and third-party software have long been part of the picture.

Companies should therefore ensure, both contractually and operationally, that they receive quickly usable security information from their supply chain. Clear escalation contacts, defined response times and the obligation to pass on relevant security information are not mere formalities. They are a prerequisite for responsiveness.

Why the CRA is becoming particularly important now

Against this background, the Cyber Resilience Act is far more than just another regulatory initiative. It addresses precisely the capabilities that companies need anyway in view of an accelerated vulnerability landscape: security by design and by default, technical documentation, continuous vulnerability management, update obligations and clear responsibilities along the supply chain. For many B2B products, this is no longer a marginal topic, but a very concrete regulatory requirement.

Many companies still associate the CRA primarily with the year 2027. In fact, the first key obligations apply earlier. From 11 September 2026, the CRA reporting obligations for actively exploited vulnerabilities and severe security incidents will begin to apply. An early warning must then be submitted to the competent CSIRT and to ENISA without undue delay, and in any event within 24 hours of becoming aware of the issue. A full notification must follow within 72 hours. For actively exploited vulnerabilities, a final report must generally be submitted no later than 14 days after a corrective or mitigating measure is available; for severe security incidents, the final report is generally due within one month. In addition, manufacturers must inform affected users without undue delay about the incident or the actively exploited vulnerability and about possible corrective measures. In practice, this is therefore not only about regulation, but about robust 24/72-hour reporting processes: clear intake channels, reliable triage, fixed escalation routes, coordinated communication paths and the ability to assess affectedness very quickly and reliably.

There is another point as well: companies that set themselves up properly now do not only reduce regulatory risks. They can also use compliance as a quality feature in the market. Especially in the B2B environment, this is likely to become significantly more important in the coming years.

Conclusion

The development described by the BSI is not a distant future scenario that companies can simply observe with interest. It is a warning signal.

If AI systematises the search for vulnerabilities, the pressure on companies increases immediately. In that situation, risk is no longer determined solely by the quality of development, but also by the quality of internal processes.

Companies should therefore now secure three things above all: clear processes, reliable product transparency and rapid responsiveness across the supply chain. The CRA makes many of these elements mandatory; the threat landscape already makes them necessary today.

This is also where it becomes clear that CRA compliance is not a pure documentation project. Anyone who wants to implement the requirements reliably must think product analysis, vulnerability management, reporting processes, technical documentation and development processes together.

This is exactly where ISiCO supports companies in practice: from CRA relevance checks and product analysis to the design of robust vulnerability and incident reporting processes and the integration of the requirements into existing development, update and governance structures. This turns regulatory pressure into a technically and organisationally sustainable implementation programme.