CRA, NIS2 and DORA-EU: EU software regulation for teams using agents

Three EU laws govern the software that coding agents help ship, plus GDPR for the data agents see: the Cyber Resilience Act (CRA) for products with digital elements, NIS2 for essential and important entities, and DORA-EU for financial entities. CRA vulnerability and incident reporting has applied since 11 September 2026; SBOM and the other duties apply from 11 December 2027.

Two weeks after 11 September 2026, a customer’s security team asks for your vulnerability disclosure policy, your 24-hour Cyber Resilience Act reporting procedure and an SBOM for the release they run. Most of last quarter’s dependency bumps came through Claude Code, Codex and Cursor, a reviewer approved each pull request, and nobody can say which new packages were checked, by whom, or against what.

This page is for the CTO who answers that questionnaire and the executive who signs the reply. It is an engineering reading of the legal texts, not legal advice. The AI Act, which covers the agents rather than the software they write, has its own page.

Sources and how they were checked

The legal texts are Regulation (EU) 2024/2847 (CRA), Directive (EU) 2022/2555 (NIS2), Regulation (EU) 2022/2554 (DORA-EU, the Digital Operational Resilience Act, not the DORA delivery metrics) and Regulation (EU) 2016/679 (GDPR). EUR-Lex was unreachable on 2026-09-26, so the articles were read in Official Journal text from public GitHub mirrors (the CRA as corrected on 2024-11-20). Check the consolidated text before you quote an article in a contract.

What this page gives a CTO facing EU software regulation

• A decision table of which law reaches you, and in which role, plus the CRA timeline.
• A map from agent failures to CRA provisions, controls, evidence and metrics.
• A tested CI dependency gate, an SBOM command and agent approval settings.
• A four-clock incident table, a 24-hour runbook, a register template, two prompts and five executive questions.

Which EU software laws reach a company that uses coding agents?

The laws attach to what you ship and your sector, not to how the code was written. Work down this table per legal entity and per product line.

If you…	Law	Your role	What it asks of you
Place software, or a device with software, on the EU market in the course of a commercial activity, paid or free	CRA	Manufacturer (Art. 3(13))	Annex I requirements, component due diligence, SBOM, vulnerability handling, Article 14 reporting, CE marking
Run a backend without which that product cannot perform a function	CRA	The backend is the product’s remote data processing (Art. 3(2))	The same requirements reach the backend
Sell only a web service (SaaS) with no product attached	CRA, generally not	Out of scope as a product (Eclipse ORC WG FAQ)	Look at NIS2, DORA-EU and GDPR
Are medium-sized or larger in a sector listed in NIS2 Annex I or II, such as cloud or managed services (Art. 2(1))	NIS2	Essential or important entity	Risk management (Art. 21), management-body accountability (Art. 20), incident reporting (Art. 23), via national law
Are a bank, payment or e-money institution, investment firm, insurer or another entity listed in Art. 2	DORA-EU	Financial entity	ICT risk, change management, incident reporting and third-party risk, from 17 January 2025
Supply software or services to a financial entity	DORA-EU, by contract	ICT third-party service provider (Art. 3(19))	Your client registers the arrangement and puts the Art. 30 terms in your contract
Let agents read code, tickets, logs or databases that contain personal data	GDPR	Controller; the agent vendor is usually your processor	Processor contract (Art. 28), minimisation (Art. 5(1)(c)), breach notification (Art. 33), lawful transfers (Chapter V)

Most software companies land in two or three rows. Where DORA-EU overlaps NIS2, DORA-EU prevails (NIS2 Art. 4).

Custom development is not automatically out of scope

Custom software built for one business client is in scope of the CRA. The Commission’s guidance, as recorded by the Eclipse ORC WG, lets the parties depart only from secure-by-default configuration and free security updates. Whoever places the product on the market under their name is the manufacturer, so software houses should read their contracts.

When do the Cyber Resilience Act obligations apply?

The CRA entered into force on 11 December 2024. Article 71 stages its application, and Article 69 decides which products already on the market it reaches.

Date	What applies	Which products
11 Sep 2026	Article 14: reporting of actively exploited vulnerabilities and severe incidents	Every in-scope product, including those placed on the market before 11 December 2027 (Art. 69(3))
11 Dec 2027	Everything else: Annex I essential requirements, SBOM, vulnerability handling, conformity assessment, CE marking	Products placed on the market from this date, and older products only if substantially modified afterwards (Art. 69(2))

So reporting is already live for software you shipped years ago, and the pipeline that produces SBOM and due-diligence evidence has to be running before December 2027, not built after it.

Breaching Annex I or Articles 13 and 14 risks fines of up to €15 million or 2.5% of worldwide annual turnover, whichever is higher (Art. 64). Micro and small enterprises cannot be fined for a late 24-hour early warning, nor open-source software stewards at all (Art. 64(10)).

What does CRA Article 14 ask from 11 September 2026?

Article 14 creates two reporting duties with the same shape. Notifications go through the single reporting platform that ENISA runs (Art. 16), to the CSIRT designated as coordinator in the member state of your main establishment, and simultaneously to ENISA.

Trigger	Early warning	Notification	Final report
An actively exploited vulnerability in your product: reliable evidence that a malicious actor exploited it without the owner’s permission (Art. 3(42))	Within 24 hours of becoming aware, naming the member states where the product is available	Within 72 hours: the exploit, the vulnerability, corrective measures and what users can do	14 days after a fix or mitigation is available
A severe incident affecting the security of your product (Art. 14(5))	Within 24 hours, saying whether it is suspected to be malicious	Within 72 hours: initial assessment and mitigating measures	One month after the notification

You must also tell impacted users which mitigations they can deploy (Art. 14(8)). An incident is severe where it “has led or is capable of leading to the introduction or execution of malicious code in a product with digital elements or in the network and information systems of a user” (Art. 14(5)(b)). A malicious package that an agent pulled into a release is exactly that, and the manufacturer reports whether a person or an agent added it.

How do slopsquatting and dependency drift meet the CRA?

Coding agents change dependencies often, and they add a failure people rarely produce: confidently referencing a package that does not exist. The OWASP GenAI LLM Top 10 2026 (LLM04 Supply Chain, published 4 August 2026) names the attack: coding assistants “hallucinate plausible but nonexistent package names at scale”, which attackers register in advance, called slopsquatting. The study it cites, Spracklen et al. at USENIX Security 2025, found that about one in five package references in LLM-generated code (19.7% across 16 models) named a package that does not exist. That figure is secondary: it comes from summaries by Aikido Security and the Cloud Security Alliance, and the paper itself was not read.

Each agent failure lands on a specific CRA provision:

Agent failure	CRA provision it meets	Control	Evidence it leaves
Adds a non-existent package, or one an attacker registered under a hallucinated name	Art. 13(5) due diligence; Annex I Part I (2)(a); Art. 14(5)(b) if malicious code ships	CI gate: each new direct dependency exists on the registry and is on the approved list	Gate log per pull request; who approved the list entry, and when
Adds a real but brand-new, unmaintained or typosquatted package	Art. 13(5)	The gate warns on recently published packages; a named person approves	Approval record with the reason
Leaves versions unpinned, so the next install resolves something new (dependency drift)	Annex I Part II (1): SBOM	Committed lockfile; CI installs only from it	SBOM from the lockfile per release
Bumps a vulnerable component inside a large feature change	Annex I Part II (2): security updates separate from feature updates where feasible	One pull request per security fix, stated in the agent’s instructions	Release notes listing security fixes separately
Patches a vendored open-source component and moves on	Art. 13(6): report to the maintainer and share the fix	Upstream-report step in the runbook	Link to the upstream issue
Ships without anyone knowing what went in	Annex I Part II (1) and (3): SBOM, security testing	SBOM and vulnerability scan per release	Both archived with the release

Build the dependency controls into the pipeline

These controls produce the CRA evidence without a person reading every dependency change. The CI gate enforces on every change, whoever wrote it; agent-side settings only slow the agent down, because an agent can edit a manifest without running an install command.

1. Keep an approved-dependency list in the repository. One package name per line in docs/compliance/approved-dependencies.txt, changed only with approval from a security or platform code owner. Its history is your due-diligence record.

2. Block unapproved and non-existent dependencies in CI. This script fails when a new direct dependency is missing from the approved list or does not exist on the npm registry, and warns when a package was first published less than 90 days ago, a common trait of slopsquatted names.

   #!/usr/bin/env bash
   # scripts/check-new-deps.sh: run on pull requests (tested with npm 10.9 and jq)
   set -euo pipefail
   BASE="${BASE_REF:-origin/main}"
   deps() { jq -r '((.dependencies // {}) + (.devDependencies // {})) | keys[]' | sort -u; }
   comm -13 <(git show "$BASE:package.json" | deps) <(deps < package.json) > new-deps.txt
   status=0
   while read -r dep; do
     if ! grep -qxF "$dep" docs/compliance/approved-dependencies.txt; then
       echo "::error::$dep is not in docs/compliance/approved-dependencies.txt"; status=1
     fi
     if ! created=$(npm view "$dep" time.created 2>/dev/null); then
       echo "::error::$dep does not exist on the npm registry (possible hallucinated name)"; status=1; continue
     fi
     if [ "$(date -d "$created" +%s)" -gt "$(date -d '90 days ago' +%s)" ]; then
       echo "::warning::$dep was first published on $created, less than 90 days ago"
     fi
   done < new-deps.txt
   exit "$status"

   Run it as a required check on every pull request; the workflow file, a Python variant and the CODEOWNERS rules are in dependency checks for agent changes.

3. Generate an SBOM for every release. npm 10 ships a built-in generator. Run it in the release job and archive the file with the build:

   # Release job: CycloneDX SBOM from the lockfile, production dependencies only
   npm sbom --sbom-format cyclonedx --package-lock-only --omit dev > sbom.cdx.json

   The CRA asks for “a commonly used and machine-readable format covering at the very least the top-level dependencies” (Annex I Part II (1)); CycloneDX and SPDX (--sbom-format spdx) both qualify. It belongs in the technical documentation (Annex VII), not necessarily in public.

4. Scan every release for known vulnerabilities. For example, OSV-Scanner (osv-scanner scan source -r .) checks the lockfiles in a directory tree against the OSV database. Archive the report next to the SBOM. A finding with known exploitation starts the Article 14 runbook below.

5. Make the agent ask before it installs. This is the speed bump, set centrally so developers cannot switch it off. The settings differ by tool:

   Claude Code

   Put an ask rule in managed settings (on Linux, /etc/claude-code/managed-settings.json; on macOS, /Library/Application Support/ClaudeCode/managed-settings.json). Claude Code evaluates ask and deny rules even when a hook returns “allow”, so a project cannot override them.

   {
     "permissions": {
       "ask": [
         "Bash(npm install *)", "Bash(npm i *)", "Bash(pnpm add *)",
         "Bash(pnpm install *)", "Bash(yarn add *)", "Bash(bun add *)",
         "Bash(pip install *)", "Bash(uv add *)"
       ]
     }
   }

   The list is illustrative: install commands have more spellings than any pattern list covers, which is why the CI gate in step 2 is the control. Run /status and check that the setting sources include the managed file.

   Codex

   Put a prefix rule in the admin-enforced requirements.toml (on Linux, /etc/codex/requirements.toml). Codex applies the most restrictive result across layers, and requirements.toml accepts only prompt or forbidden. Checked against the Codex source on 2026-09-26 (codex-cli 0.157.1).

   [[rules.prefix_rules]]
   pattern = [{ token = "npm" }, { any_of = ["install", "i", "add"] }]
   decision = "prompt"
   justification = "New dependencies need an approved-list entry (CRA Art. 13(5))"
   
   [[rules.prefix_rules]]
   pattern = [{ token = "pip" }, { token = "install" }]
   decision = "prompt"
   justification = "New dependencies need an approved-list entry (CRA Art. 13(5))"

   Cursor

   Cursor’s hook events and team-level enforcement could not be verified against cursor.com on 2026-09-26, so no configuration is printed here. Rely on the CI gate, plus a project rule that new dependencies need an entry in docs/compliance/approved-dependencies.txt.

A compliance position decays with every merged pull request unless something re-checks it. Track each control with one metric:

Control	Metric and target	Owner, cadence
Dependency gate	Gate coverage: merged pull requests that changed a manifest and passed the gate, 100%	Platform team, every pull request
SBOM and scan	Releases with an archived SBOM and scan report, 100%	Release owner, every release
Reporting drill	Time to early warning, from injected awareness to a submitted draft, well under 24 hours	Security lead, twice a year and after on-call changes
Register and vendors	Every distributed artifact reviewed this quarter; every agent vendor on current processor (and, for financial clients, DORA-EU) terms	CTO with counsel and procurement, quarterly

Who does NIS2 reach, and what does it ask of the pipeline?

NIS2 applies to medium-sized and larger entities of a type in its Annex I or II, and to some smaller ones regardless of size (Art. 2). For a software company the usual entry points are cloud computing and managed services, including operating or maintaining customers’ applications (Art. 6(39)). It applies through national law from 18 October 2024 (Art. 41).

Article	What it says	What it means for agent-authored change
Art. 20	The management body approves and oversees risk-management measures, can be held liable and must be trained	The board signs off the agent policy and change gates, not only the CTO
Art. 21(2)(d)	Supply chain security, including direct suppliers and service providers	Coding-agent vendors and MCP servers are suppliers. Assess them like any other
Art. 21(2)(e)	Secure development and maintenance, including vulnerability handling	The dependency gate, SBOM and runbook are the evidence
Art. 23	Significant incidents: early warning at 24 hours, notification at 72 hours, final report at one month	An agent-caused outage can qualify; the clock starts at awareness

Article 21(2) also lists access control, so an agent running with a developer’s full credentials is a finding; see agent identity, credentials and secrets. National law sets the fines within Article 34: a maximum of at least €10 million or 2% of worldwide turnover for essential entities, and at least €7 million or 1.4% for important entities.

In Poland the transposing law is an amendment to the ustawa o krajowym systemie cyberbezpieczeństwa; ISAP could not be reached on 2026-09-26, so this page does not cite its provisions.

What does DORA-EU ask of financial entities whose code agents write?

DORA-EU has applied directly since 17 January 2025 (Art. 64); it is unrelated to the DORA delivery metrics and the DORA AI Capabilities Model. Four provisions decide how a financial entity can use coding agents:

• The management body owns ICT risk. It bears “the ultimate responsibility for managing the financial entity’s ICT risk” (Art. 5(2)), so agent adoption is its decision, not a team’s tool choice.
• Change management must be controlled. “All changes to ICT systems are recorded, tested, assessed, approved, implemented and verified in a controlled manner” (Art. 9(4)(e)). An agent-authored change needs the same record as a human one; the evidence bundle is designed as that record.
• Coding-agent vendors are ICT third-party service providers (Art. 3(19)). Anthropic, OpenAI and Anysphere each go into the register of information (Art. 28(3)) after due diligence (Art. 28(4)), with the Article 30 terms in the contract.
• Major ICT-related incidents are reported to the competent authority (Art. 19), with time limits set in the Commission’s delegated and implementing acts.

If you sell to a financial entity, DORA-EU reaches you through the contract: audit rights, exit terms and questions about how agent-written changes are approved. See regulated industries for separation of duties.

How does GDPR apply to agent data flows?

GDPR applies whenever an agent sees personal data, and agents see more than people expect: test fixtures, pasted log excerpts, a production database behind an MCP server, a customer ticket. Map each flow before you widen agent access.

Flow	GDPR question	Control
Prompts, code and tool output sent to the model vendor	Processor contract (Art. 28)? Transfers outside the EEA (Chapter V)?	Enterprise terms with a data processing agreement; choose where the model runs
Agent reads a database or ticket system through an MCP server	Is access limited to what the task needs (Art. 5(1)(c)) and designed in (Art. 25)?	Read-only MCP credentials against an anonymised or synthetic copy
Transcripts on developer machines	Retention: Claude Code keeps them in ~/.claude/projects/ for 30 days by default (cleanupPeriodDays); Codex in ~/.codex/sessions/ (codex-cli 0.157.1)	Set retention centrally; cover the directories in data-loss rules
Personal data leaks through an agent	Notify the supervisory authority within 72 hours where feasible (Art. 33)	The runbook below; the agent threat model

Vendor retention modes and training opt-outs are on data privacy and enterprise policies.

One agent incident, four reporting clocks

Suppose an agent adds a slopsquatted package that ships in your desktop app and sends customer tokens to an attacker. That is a severe incident under the CRA, possibly a significant incident under NIS2, a major ICT-related incident if you are a financial entity, and a personal data breach under GDPR.

Law	Report to	First deadline	Then
CRA Art. 14	Coordinator CSIRT and ENISA, via the single reporting platform	Early warning, 24 hours	Notification at 72 hours; final report; inform users
NIS2 Art. 23 (national law)	National CSIRT or competent authority	Early warning, 24 hours	Notification at 72 hours; final report at one month
DORA-EU Art. 19	Financial competent authority	Per the delegated and implementing acts	Intermediate and final reports; inform affected clients
GDPR Art. 33	Supervisory authority (in Poland, the President of UODO)	72 hours where feasible	Inform data subjects if the risk is high (Art. 34)

The first 24 hours, assuming a named incident lead and a security on-call rotation:

1. Hour 0: record the moment of awareness, with its source. Every clock starts there.

2. Hours 0 to 4: classify against all four laws, recording each answer with its reason.

3. Hours 4 to 12: identify affected versions and member states from the SBOM archive and sales data.

4. Hours 12 to 24: send each early warning that applies. An early warning with incomplete facts is compliant; a late complete one is not.

5. Before the 72-hour mark: send the notifications and publish the user advisory the CRA requires.

6. After the fix: report upstream and close out. Share the fix with the component’s maintainer (CRA Art. 13(6)), file the final reports, and add a regression test and a gate change; see when an agent causes an incident for the review.

Keep one applicability register

The register answers customer questionnaires and records who decided each classification, one entry per product or service:

docs/compliance/eu-regulation-register.yaml

- id: desktop-client
  owner: "team-client-platform"
  cra:
    role: manufacturer            # manufacturer | importer | distributor | out-of-scope
    product_type: software        # software | hardware | remote-data-processing
    support_period_until: 2032-12-31   # at least five years (Art. 13(8))
    csirt_coordinator: "CSIRT of the main establishment's member state"
    sbom: "release artifacts: sbom.cdx.json"
    cvd_policy: "https://example.com/security/disclosure"
  nis2: { entity: important, national_law: "check transposing act" }
  dora_eu: { financial_entity: false, supplies_financial_entities: true }
  gdpr: { personal_data: true, processors: [Anthropic, OpenAI] }
  agent_controls:
    dependency_gate: "scripts/check-new-deps.sh"
    approved_list: "docs/compliance/approved-dependencies.txt"
  reviewed: 2026-09-26
  reviewer: "cto"

Copy-paste prompts to map your regulatory exposure

Run these from the repository root in Claude Code, Codex or Cursor. They are identical across tools.

Copy-paste prompt: map products to the CRA and draft the register

Read this repository's build and release configuration (package.json,
pyproject.toml, Dockerfiles, CI workflows, installers and app store
manifests) and our README and docs/.

For each thing we ship, report: whether it is distributed to customers as
software or firmware, or only runs as a hosted service; which backend
services the shipped software cannot perform its functions without; how
security updates reach users today; and whether security fixes ship
separately from feature releases.

Output entries in the format of docs/compliance/eu-regulation-register.yaml.
Mark every legal classification as "NEEDS REVIEW" with the evidence you
found. Do not decide whether we are a manufacturer; list the facts that
decide it.

Copy-paste prompt: audit dependency changes made by agents

Using git log for the last 90 days, list every commit that changed a
dependency manifest or lockfile (package.json, package-lock.json,
pyproject.toml, uv.lock, requirements*.txt, go.mod, go.sum).

For each newly added direct dependency, report: the commit, its author and
any Co-Authored-By trailer that names an agent, the pull request if the
message references one, whether the package is in
docs/compliance/approved-dependencies.txt, and when the package was first
published on its registry (run `npm view <name> time.created` or query the
PyPI JSON API). Flag packages first published less than 90 days before
they were added, and names within one edit of a popular package.

Output a table sorted by risk. Do not modify any file.

Treat both outputs as drafts: the CTO signs each classification with counsel, and every flagged package gets an approval record or a removal pull request.

What goes wrong with EU regulation in agent-heavy teams?

Treating 11 December 2027 as the start date. Article 14 reporting already applies to products on the market. Recovery: make security on-call the owner of CRA reporting today, and run the drill this quarter.

The agent adds the dependency by editing the manifest. Command approval rules never fire because no install command ran. Recovery: the CI gate is the control; check gate coverage, not prompt counts.

The agent “fixes” the failing gate. Asked to turn a red pull request green, it adds the package to the approved list or loosens the script. Recovery: code-owner review on the gate files; a pull request touching both a manifest and the list needs a security approver.

Security fixes buried in agent feature pull requests. Users cannot take the fix without the feature. Recovery: state in CLAUDE.md or AGENTS.md that security fixes get their own pull request, and reject mixed ones.

“We are SaaS, so none of this applies.” NIS2, DORA-EU contracts and GDPR probably do, and any desktop client, mobile app, SDK or on-premises agent brings the CRA back. Recovery: fill in the register for every artifact you distribute.

Five questions an executive can ask the CTO

1. Which of our products are CRA “products with digital elements”, and who is named as the manufacturer on each?
2. If a vulnerability in one of our products were exploited tonight, who files the 24-hour early warning, and when did we last rehearse it?
3. What stops an agent from adding a package that does not exist or was registered last week, and what share of pull requests passed that check last quarter?
4. Can we produce the SBOM for the version a given customer runs, today, without rebuilding it?
5. Which of our customers are financial entities, and what have we promised them about how changes are approved?

Where to go next with EU regulation and agents

The EU AI Act for companies building software with agents The regulation that covers the agents and any AI features you ship.

Hallucinated packages and slopsquatting: dependency checks The full dependency-gate design behind the CRA evidence.

Agentic engineering in regulated industries Separation of duties and what auditors in finance and health expect.

The evidence bundle The per-change record that DORA-EU change management and CRA documentation need.

Data privacy and enterprise policies Vendor data terms, retention and GDPR for agent data flows.

When an agent causes an incident Response and post-incident review once the reporting clocks are running.