Skip to main content

EU law now expects proof: why security tooling is no longer optional

· 9 min read
Vulkro
Vulkro
Security research

For most of the last decade, a security scanner was something a software team adopted when it had the time, the budget or a nervous customer. Testing was good practice. Writing down the results was better practice. Neither was something a regulator, a court or a board could reliably hold you to.

That has changed, and 2026 is the year it became hard to ignore. Six EU laws now reach software teams, from the GDPR baseline to the new Cyber Resilience Act, and read side by side they share one demand: not that you are secure, which no law can define, but that you can show, at any moment, what you tested, what you found and what you did about it.

This is a plain-language summary of EU law for software teams, not legal advice: check the official text and your counsel before you rely on it.

The deadlines​

LawDateWhat it means for software
GDPR, Article 32since 25 May 2018Security appropriate to the risk, and a process for "regularly testing, assessing and evaluating" it
NIS2 (Directive (EU) 2022/2555)national measures from 18 October 2024Risk-management measures including secure development and supply chain security, for medium and large entities in critical sectors
DORA (Regulation (EU) 2022/2554)since 17 January 2025ICT risk management, testing and third-party risk for EU financial entities
Cyber Resilience Act (Regulation (EU) 2024/2847)reporting since 11 September 2026; the rest from 11 December 2027A 24-hour early warning for actively exploited vulnerabilities; SBOMs; no known exploitable vulnerabilities at release
Product Liability Directive (Directive (EU) 2024/2853)transposition by 9 December 2026Software is a product; a missing security update can make it defective
AI Act (Regulation (EU) 2024/1689)high-risk requirements from 2 December 2027 (Annex III) and 2 August 2028 (Annex I)Accuracy, robustness and cybersecurity for high-risk AI systems

The AI Act dates in that table are the new ones. Regulation (EU) 2026/1744, the Digital Omnibus on AI published in July 2026, moved the high-risk requirements back from 2 August 2026 and 2 August 2027. Other changes are still only proposals, including a single entry point for incident reports across NIS2, GDPR and DORA and targeted amendments to NIS2. Plan on the law as it stands.

What the laws have in common​

They ask for regular testing, in nearly the same words. GDPR Article 32 asks for a process of regular testing. The CRA's Annex I asks manufacturers to "apply effective and regular tests and reviews" of their product's security. DORA Article 25 lists vulnerability scans and "source code reviews where feasible". For cloud and managed service providers, the NIS2 implementing rules require entities to "document the type, scope, time and results of the tests". A test nobody wrote down does not count for much under any of them.

They make suppliers your problem. NIS2 lists supply chain security among its minimum measures. DORA keeps a financial entity "fully responsible" for the ICT services it buys. The CRA requires due diligence on third-party components, open-source ones included, and an SBOM that lists them. The library you did not write and the integration you did not build are now inside your boundary.

They put the board on the hook. NIS2 Article 20 says management bodies approve and oversee cybersecurity measures and "can be held liable". DORA Article 5 gives the management body "the ultimate responsibility" for ICT risk. A board that is liable will ask for evidence, and a slide that says "we scan quarterly" is not evidence.

They set clocks. The CRA and NIS2 both demand an early warning within 24 hours. DORA's standard asks for an initial notification within 4 hours of classifying an incident as major. GDPR's breach notice is due within 72 hours where feasible. Each clock assumes you already know your systems well enough to answer quickly.

Liability has moved to whoever ships the code​

The new Product Liability Directive applies to products placed on the market after 9 December 2026, and it names software as a product. A court judging whether a product was defective takes into account "safety-relevant cybersecurity requirements". A manufacturer cannot escape liability where the defect comes from software, an update, or "a lack of software updates or upgrades necessary to maintain safety", as long as those were within its control. Claims are brought by individuals, and damage now includes destroyed or corrupted personal data.

Put that next to the CRA's support period of at least five years for most products, and the conclusion is plain: shipping a fix is no longer a courtesy. It is the evidence that you kept a product safe.

The threat picture behind the laws​

The laws did not arrive in a quiet year. ENISA's Threat Landscape 2025, covering July 2024 to June 2025 and 4,875 incidents, named phishing (60%) and vulnerability exploitation (21.3%) as the two leading intrusion access points, and reported attackers intensifying their abuse of "critical dependency points", the digital supply chain included.

The Salesforce data thefts of 2025 and 2026 are a clear example of what that looks like in practice. They needed no flaw in the platform. They used trust the orgs had already granted: an employee talked into authorising a connected app, a third-party integration's stolen tokens, a guest user that could read more than anyone meant. We walked through those paths hop by hop in How Salesforce orgs get breached. Each path ran through configuration that analysis can show before an attacker uses it: who may authorise a new connected app, what an integration's token can reach, what a guest user can read.

AI speeds up development but does not change the obligations​

More and more code is written with an AI assistant. The CRA and the PLD attach to the product you ship, not to who or what typed the code. The AI Act's own cybersecurity duties in Article 15 bind high-risk AI systems, which most coding assistants and model API calls are not. For everyone else, AI-generated code is simply code, and more of it means more to review in the same week.

That is the strongest practical argument for tooling. A review process that depends on a person reading every change cannot keep pace with an assistant that writes them. An analysis that runs on every change can.

What "evidence-producing" means in practice​

Not every scanner produces evidence a regulator would recognise. Three properties make the difference:

  1. It is reproducible. The same code gives the same result, so a finding in an audit pack can be checked by someone else. Vulkro's detection is deterministic: the scan engine calls no model and spends no model tokens, and every finding states the evidence behind it (the data flow or the configuration that makes it real) or says plainly that it is unproven.
  2. It runs on every change, not once a year. A gate in the pipeline that fails a build on new findings turns "no known exploitable vulnerabilities" into a check. An annual penetration test is still worth doing; it is not a record of the other 364 days.
  3. It keeps the record. Saved scans, history and trends answer the question the laws keep asking: what did you test, when, what did you find, and what changed after.

Where Vulkro fits​

  • For software you ship (CRA, PLD): Vulkro Core writes CycloneDX and SPDX SBOMs, reachability-backed VEX statements and a CRA readiness bundle, and gates releases on new findings. Read The EU Cyber Resilience Act is live.
  • For Salesforce estates (NIS2, DORA): Vulkro for Salesforce audits code and the live org for access, third parties, detection and change, and maps findings to DORA and NIS2 articles. Vulkro Cloud for Salesforce, available by invitation, keeps that record across every org. Read NIS2 and DORA reach your Salesforce org.
  • For code that calls models: an AI bill of materials lists the SDKs, models and MCP servers in a codebase, and code findings map to the OWASP Top 10 for LLM and Agentic Applications.
  • For the GDPR baseline: findings for personal-data exposure, missing encryption and access gaps on every scan.

None of this makes anyone compliant or certified, and nothing here reports to a regulator for you. It produces the technical evidence the laws ask for, on your own machine, every time the code changes. The scan, every finding with its proof and the fix are free on one repository, with no account; the evidence formats, history and the release gate are part of Pro.

Start with one repository​

Install Vulkro, scan the code you ship, and look at the first findings with the proof behind them. The record starts with the first scan you keep.

Sources​