10 Best CRA Compliance Tools to Prepare for the 2027 Deadline

TL;DR

• The CRA runs on two clocks, not one: 24h, 72h, and 14-day reporting duties start 11 September 2026, while Annex I conformity, the technical file, and CE marking apply from 11 December 2027.
• No tool can make you CRA compliant. Conformity stays with the manufacturer, the regulation names no mandatory standard, and tooling only produces the evidence you hand an auditor.
• We judged ten tools on five criteria: requirement-ID mapping, exploited-vulnerability scoring with CVSS plus EPSS plus KEV plus CWE, runtime evidence, SBOM coverage at build and runtime, and deployment reach.
• Annex I requires no known exploitable vulnerabilities, not zero CVEs. Proving exploitability with observed runtime execution shrinks a nine-hundred-finding spreadsheet into a defensible dozen.
• CRA is four jobs, not one purchase: runtime evidence, build-time scanning and hardened images, compliance-evidence automation, and reporting infrastructure. Buying two tools for one job is the common budget error.
• If you ship an LLM, agent framework, or MCP server, it is a product with digital elements, and prompt injection or tool poisoning reaching production is a reportable security event.

Q1. Ten CRA Compliance Tools, Judged on the Evidence They Can Hand an Auditor

CRA compliance tools help manufacturers of products with digital elements meet Regulation (EU) 2024/2847: scope and class assessment, Annex I gap analysis, SBOM generation, exploitation-aware vulnerability monitoring, VEX, Annex VII documentation, and the 24h/72h/14d ENISA reporting workflow. The ones worth paying for produce timestamped, exportable evidence rather than dashboards.

Most conversations about the EU Cyber Resilience Act (not the US Community Reinvestment Act) fixate on 11 December 2027, while the reporting clock already runs on products you shipped years ago. Reading your way out is not an option: the regulation runs to 71 articles, eight annexes, and roughly 52,000 words, and "ship first, patch later" now reads as negligence with fines up to 15 million euros or 2.5% of worldwide annual turnover. So I evaluated ten tools against criteria that decide audits, not demos: requirement-ID mapping, exploited-vulnerability scoring, runtime evidence, SBOM coverage, and deployment reach. Written for the SecOps or DevSecOps lead who owns this alone.

📋 Our Evaluation Criteria

• Control-to-requirement-ID mapping. Can the tool tie a control you actually run to a named CRA or NIS2 requirement? Without that, an auditor gets screenshots instead of evidence. Our CRA and NIS2 Compliance Center was built around exactly this question.
• Exploited-vulnerability and explainability scoring. Does it combine CVSS (severity), EPSS (probability of exploitation), CISA KEV (confirmed exploitation in the wild), and CWE (weakness type)? The CRA trigger is active exploitation, not a high score.
• Runtime evidence versus posture-only reporting. Does it show what actually executed, or only what was present at build time? A VEX "not affected" claim needs a justification you can defend, which is the whole argument for runtime workload security.
• SBOM coverage, build-time and runtime. Does it emit CycloneDX or SPDX from CI, and match those components against NVD, the EU vulnerability database, and KEV?
• Deployment and data reach. Does it work self-hosted, on-prem, and air-gapped, and where does your SBOM data live? SBOMs are supply-chain intelligence, not marketing collateral.

👥 Who This Guide Is For

• SecOps and DevSecOps leads at SMBs who ship software into the EU and have no dedicated GRC function.
• Kubernetes and container runtime-security owners moving from build-time scanning to runtime detection.
• AI-workload and LLM-agent runtime-security owners whose products embed models, agents, or MCP servers.
• Compliance owners who need runtime evidence mapped to CRA and NIS2 requirement IDs before September.

🧰 The Tools Covered

• EdgeLabs: Best for teams needing runtime detection, response, and CRA evidence that keeps working with no cloud backend.
• Sysdig: Best for cloud-native platform teams wanting mature, Falco-rooted runtime security across multiple clouds.
• Aqua Security (Trivy): Best for catching known vulnerabilities and bad defaults right after the build, in the pipeline.
• Falco (CNCF): Best for teams that want an open-source syscall rules engine they run and tune themselves.
• Oligo Security: Best for application-layer runtime analysis of library behavior in production.
• Upwind Security: Best for cloud teams wanting runtime context layered onto cloud posture findings.
• CrowdStrike: Best for organizations already standardized on an endpoint agent estate.
• SentinelOne (Singularity Cloud): Best for endpoint-first teams extending one console into cloud workloads.
• Chainguard: Best for eliminating OS-level CVEs at the source with rebuilt, signed base images.
• Drata: Best for automating the audit-evidence and questionnaire side that runtime tools do not touch.

📊 Master Comparison Table

Total providers: 10.

Darktrace and Vectra AI come up in these conversations. Both are network-first and cloud-dependent by design, so I mention them only to draw the category line, not as CRA evidence tools.

🗣️ What Practitioners Are Actually Saying

The shift from one-off document to continuous obligation is the thing operators keep naming.

"The EU Cyber Resilience Act is changing SBOMs from a point-in-time compliance document to a continuous lifecycle requirement."
u/[poster], r/devsecops Reddit Thread

And the buying question is still unresolved for most teams, which is exactly why this list is criteria-first.

"With the EU Cyber Resilience Act deadline getting closer, I'm curious how others are approaching this in practice."
u/[poster], r/cybersecurity Reddit Thread

🔍 Why I Judge These Tools on Evidence, Not Features

Every vendor on this list will tell you it "supports CRA compliance." None of them can be compliant on your behalf. Conformity stays with the manufacturer, and the regulation names no mandatory tool or standard.

What separates the ten is narrower than the marketing suggests. Some produce artifacts an auditor can read. Some produce a dashboard that expires when your subscription does.

EdgeLabs' own read, from deployments where the cloud link was cut on purpose, is that the artifact question decides everything. If your evidence lives only in someone else's console, you do not own your audit trail. Our practical CRA readiness roadmap walks through the same reasoning step by step.

1.1 EdgeLabs

1 out of 10

"Good IPS/IDS/EDR software. Webportal management is good. Docker container integration is useful." Dislike: "Nothing major. Description of issues can be complicated for non-technical folks." Problems solved: "SOC2 compliance mainly." (4 stars)

Verified User in Computer Software · EdgeLabs G2 - Verified Review

"It's beneficial to secure any website or any server from hackers." Dislike: "I don't think there is any option for dislike but the commercial seems high." (4.5 stars)

Abhishek A. · EdgeLabs G2 - Abhishek A. Verified Review

1.2 Sysdig

2 out of 10

1.3 Aqua Security (Trivy)

3 out of 10

1.4 Falco (CNCF)

4 out of 10

1.5 Oligo Security

5 out of 10

1.6 Upwind Security

6 out of 10

1.7 CrowdStrike

7 out of 10

1.8 SentinelOne (Singularity Cloud)

8 out of 10

1.9 Chainguard

9 out of 10

1.10 Drata

10 out of 10

⚖️ What This Roster Actually Tells You

Ten tools, four different jobs. Nobody sells one box that closes CRA, and any vendor claiming otherwise is selling you an audit finding.

Practitioners keep landing in the same place when they compare notes on this.

"The EU Cyber Resilience Act is changing SBOMs from a point-in-time compliance document to a continuous lifecycle requirement."
u/[poster], r/devsecops Reddit Thread

Continuous is the operative word. A scan you ran in March proves nothing about a vulnerability exploited in October.

🧩 The Stack I Would Actually Assemble

Start with hardened images to shrink the problem. Add pipeline scanning that blocks builds. Add runtime detection that records what executed. Add a governance platform for the paperwork.

Edge Labs AI covers the runtime detection, response, and exploited-vulnerability evidence layer of that stack, with the Compliance Center mapping those controls to named CRA and NIS2 requirement IDs, and it keeps recording when the backend is unreachable. The paperwork layer is somebody else's job, and I would rather tell you that now than during your audit. If you want to see the reasoning behind that split, our note on why NIS2 and CRA change the game lays it out, or you can talk to our team about your own estate.

Q2. What Does the CRA Require, by When, and for Which of Your Products?

Three dates matter. From 11 September 2026, manufacturers report actively exploited vulnerabilities and severe incidents within 24 hours, 72 hours, and 14 days, including for products already on the market. By 11 December 2026, Member States designate notified bodies. From 11 December 2027, Annex I requirements, the Annex VII technical file, and CE marking apply in full.

⏰ Two Clocks, Not One

The Cyber Resilience Act runs on two separate timers, and most teams only see the second one. The reporting clock starts 11 September 2026. The full-conformity clock starts 11 December 2027.

That gap matters because the two demand different things. Reporting needs detection and a workflow. Conformity needs design evidence and documentation.

⚠️ Why the 2027 Focus Is a Trap

I keep meeting teams building a beautiful 2027 audit file while carrying an unmanaged 24-hour obligation from next month. The paperwork feels controllable. The 24-hour clock does not.

Edge Labs AI's read is that the standard advice gets this backwards, because documentation can be written late while an exploitation event cannot be detected late. You can catch up on a technical file. You cannot retroactively notice a breach, which is why our practical CRA readiness roadmap starts with detection.

📦 What Counts as a "Product With Digital Elements"

A product with digital elements is any software or hardware product that can connect to a device or network. That definition is wide on purpose.

SaaS is not automatically out of scope. If your service is the remote data processing that makes a product work, it is pulled in. A pure website with no product behind it stays out.

✅ A Quick Scoping Test

Ask three questions about each thing you sell. Is it software or hardware you place on the EU market? Does it connect to anything? Is it sold, not just used internally?

Three yes answers means you are in scope. Write the determination down with a date and an owner, because "we assumed we were exempt" is not a defence.

🏷️ Your Product Class Decides Your Cost

The CRA sorts products into three buckets, and the bucket sets your conformity route. Roughly 90% of products land in the default class, where you self-assess.

Here is the sequencing problem nobody warns you about. If no harmonised standard exists for your product, external evaluation by a lab becomes your only route.

⚠️ The Notified-Body Bottleneck

Notified bodies must be designated by Member States before they can assess anything. Class II and critical manufacturers are queuing for capacity that does not fully exist yet.

Put a calendar hold in Q1 2027 now if any product is Class II or critical. Booking assessment in late 2027 for a December 2027 deadline is not a plan.

🕰️ The Legacy-Product Trap

Transitional arrangements let products placed on the market before 11 December 2027 stay available without full conformity assessment. Those arrangements do not touch reporting.

So a product you shipped in 2019 and barely think about still generates a 24-hour obligation from 11 September 2026. Edge Labs AI sees this gap most often in long-lived deployments where nobody currently monitors what those older versions are running, which is the same pattern our work on distributed edge infrastructure keeps surfacing.

💸 What Non-Compliance Actually Costs

Article 64 sets three tiers, and the higher of the two figures always applies. Breaching Annex I essential requirements or the Article 14 reporting duties sits in the top tier at 15 million euros or 2.5% of worldwide annual turnover.

• Top tier (Art. 64(2)): 15 million euros or 2.5% of global turnover, covering Annex I breaches, Article 13 manufacturer duties, and failure to report exploited vulnerabilities.
• Mid tier (Art. 64(3)): 10 million euros or 2%, covering a missing EU Declaration of Conformity, improper CE marking, and inadequate conformity assessment.
• Lower tier (Art. 64(4)): 5 million euros or 1%, for incorrect or misleading information given to authorities.
• Beyond fines: market withdrawal, prohibition, and recall orders, which usually hurt more than the cash.

✅ One Piece of Genuinely Good News

Microenterprises and small enterprises are exempt from fines specifically for missing the 24-hour and 72-hour reporting deadlines under Article 14. Open-source software stewards are exempt from all administrative fines, though the underlying obligations still apply.

That exemption is narrower than it sounds. Security-requirement and documentation violations still carry fines, with company size treated only as a mitigating factor.

❌ No Standard Is Mandatory, So No Tool Certifies You

The CRA names no required standard. ISO 27001:2022 and ENISA guidance are voluntary pathways that help you argue Annex I conformity, not certificates of it.

Any vendor telling you their product makes you CRA compliant is describing something that cannot exist. Conformity sits with the manufacturer, permanently.

Edge Labs AI ships a CRA/NIS2 Compliance Center that maps each runtime control to a named requirement ID, including the Annex I "No Known Exploitable Vulnerabilities" check. That means the 2027 technical file assembles from live evidence rather than screenshots taken the week before an audit. What it does not cover is governance and lifecycle paperwork, and I would rather say so upfront. Our explainer on why NIS2 and CRA change the game for edge AI security sets out the reasoning behind that split.

Q3. How Should You Evaluate a CRA Compliance Tool?

Judge CRA tooling on five things: control-to-requirement-ID mapping depth; exploited-vulnerability and explainability scoring using CVSS, EPSS, CISA KEV, and CWE together; runtime enforcement evidence versus posture-only reporting; SBOM coverage at both build time and runtime in CycloneDX or SPDX; and deployment reach, including self-hosted, on-prem, and air-gapped environments where evidence must still be generated.

📋 The Five Criteria, and What Each One Actually Tests

Score each tool one to five on these. An SMB buyer with no GRC function can finish this in an afternoon.

• Requirement-ID mapping depth. Does a control you run link to a named CRA article or Annex clause? Without that link, an auditor gets a dashboard and a story instead of evidence.
• Exploited-vulnerability and explainability scoring. CVSS gives severity. EPSS gives the probability a CVE will actually be exploited, using a machine-learning model trained on real exploitation data. CISA KEV confirms exploitation in the wild. CWE names the weakness type. You need all four, because the CRA trigger is active exploitation, not a scary number.
• Runtime enforcement evidence. Can the tool show what executed, or only what was installed? A "not affected" claim needs observed behavior behind it, which is the core of runtime workload and application security.
• SBOM coverage, build and runtime. Does it emit CycloneDX or SPDX from CI, and does it also know which components actually loaded in production? The two lists are never identical.
• Deployment and data reach. Does it generate evidence with no egress, and where does your SBOM data live? SBOMs are supply-chain intelligence about your own product.

⚠️ The Criterion Almost Nobody Scores Honestly

Edge Labs AI scores findings with CVSS, EPSS, CISA KEV, and CWE together, then states which findings are exploitable in the running workload. I weight this criterion highest, and I will admit that is partly a bet rather than a settled fact. You can see how that exploitation-aware vulnerability management is put together before you take my word for it.

CVSS-first patching is the default habit, and it quietly wastes most of a small team's remediation time. You fix what looks frightening on paper instead of what attackers are using this week.

❌ Installed Is Not Configured

Across the runtime deployments Edge Labs AI has run, something is misconfigured essentially every time we look. Security tools sit installed with no policy attached.

Teams almost get it right and just do not press the last button. So add a sixth informal test to your evaluation: after week one, does the tool tell you it is not actually enforcing anything? Our note on how the agent works covers what enforcement should look like on day one.

👥 Who This Rubric Is For

• SecOps and DevSecOps leads at SMBs who own CRA readiness without a compliance team behind them.
• AI-workload and LLM-agent runtime-security owners shipping products that embed models, agents, or MCP servers, where AI workload security becomes part of the CRA file.
• Kubernetes and container runtime-security owners moving from build-time scanning to runtime evidence.
• Compliance owners who need runtime controls mapped to CRA and NIS2 requirement IDs before September.

💰 Free Tools Are Real, and They Stop Short

Free CRA tooling is genuinely useful. Scope Fast Checks, product-class finders, Annex I compliance matrices, cost calculators, SBOM vulnerability analyzers, and Declaration of Conformity generators all shorten the scoping phase.

None of them carries continuous monitoring, an audit trail, or a reporting workflow. Use free tools to find out what you owe, then decide what to pay for.

Edge Labs AI publishes a free self-serve tier so an SMB team can test runtime detection before any conversation happens, and the tier is intentionally narrower than the enterprise deployment. I would rather you find the limits yourself than hear about them from me.

Q4. The 10 Best CRA Compliance Tools Compared

The ten tools worth shortlisting cover four jobs: runtime evidence with exploitation-aware prioritisation, build-time scanning and hardened dependencies, compliance-evidence automation, and reporting infrastructure. No tool makes you CRA compliant, because conformity stays with the manufacturer and tooling only produces the evidence.

🧭 Four Jobs, Not One Product

The mistake I see most is treating CRA as one purchase. It is four jobs, and different vendors own different ones.

Runtime evidence answers what executed. Build-time scanning and hardened images shrink the problem. Compliance automation handles attestation. Reporting infrastructure moves the notification.

⚠️ Where Edge Labs AI Does Not Belong

Edge Labs AI is not a GRC questionnaire platform, not a static analysis tool, and not a substitute for a notified body. Naming that upfront saves us both a wasted call, and if you want the fuller argument, here is where we do fit.

I am neutral on individual tools and opinionated about categories. Buying two tools that do the same job is the most common CRA budget error I see.

📊 Which Tool Fits Which Situation

• EdgeLabs: Best for runtime detection, response, and CRA evidence in self-hosted or air-gapped environments.
• Sysdig: Best for multi-cloud Kubernetes teams wanting mature, Falco-rooted runtime security.
• Aqua Security (Trivy): Best for pipeline scanning with a documented offline database workflow.
• Falco (CNCF): Best for teams that want an open-source syscall rules engine they operate themselves.
• Oligo Security: Best for narrowing library CVE lists using observed runtime behavior.
• Upwind Security: Best for cloud posture teams adding runtime context via eBPF sensors.
• CrowdStrike: Best for large existing endpoint estates extending into containers.
• SentinelOne (Singularity Cloud): Best for endpoint-first teams consolidating consoles.
• Chainguard: Best for deleting OS-layer CVEs before they ever reach a report.
• Drata: Best for the governance and audit-evidence work runtime tools cannot touch.

Total providers: 10.

❌ Tools I Deliberately Left Off the Cards

Darktrace and Vectra AI come up constantly. Both are network-first and cloud-dependent, so they mark a category boundary rather than a CRA evidence option, a line our breakdown of CADR tools draws in more detail.

A few adjacent tools solve real but different problems. Static analysis platforms turn a scan into a release decision, device-control tools run hundreds of daily posture checks per endpoint, and OTA update frameworks like SWUpdate or Hawkbit deliver the security updates Annex I requires. None of them produces runtime exploitation evidence, so none earned a card here.

🗣️ What Practitioners Say About This Buying Problem

"The EU Cyber Resilience Act is changing SBOMs from a point-in-time compliance document to a continuous lifecycle requirement."
u/[poster], r/devsecops Reddit Thread

"With the EU Cyber Resilience Act deadline getting closer, I'm curious how others are approaching this in practice."
u/[poster], r/cybersecurity Reddit Thread

"Good IPS/IDS/EDR software. Webportal management is good. Docker container integration is useful." Dislike: "Description of issues can be complicated for non-technical folks."
Verified User in Computer Software EdgeLabs G2 - Verified Review

🧩 How I Would Actually Sequence the Spend

Start by shrinking the problem with hardened base images, since a CVE that never appears needs no justification. Then make scanning a blocking CI step that emits a versioned SBOM.

Only then buy runtime detection, and buy governance automation last. Spending on evidence collection before you have reduced the noise is how teams end up paying to triage findings they could have deleted. Our roundup of container runtime security tools maps that sequence onto specific product categories.

Edge Labs AI takes position one here as the only entry running both detection and response entirely on the agent with no cloud dependency, consolidating vulnerability management, EDR, NDR, IPS/IDS, and Kubernetes security into a footprint published at typically under 5% CPU. Its published Trader Joe's case study reports an 83% MTTR reduction and 573% ROI, and those are self-reported figures.

Q5. What Separates Real CRA Evidence From Compliance Theatre?

The Commission's Q&A clarifies that manufacturers must ship without known exploitable vulnerabilities, not without all vulnerabilities. Non-exploitable vulnerabilities do not breach the CRA. So the work is proving exploitability: correlate SBOM components against CISA KEV and EPSS, then justify every VEX not_affected status with evidence of what actually executed at runtime.

❌ The Zero-CVE Myth Is Wrong, and Expensive

Almost everyone reads Annex I as "no vulnerabilities allowed." That reading is wrong, and it costs teams entire quarters.

The Commission's own Q&A specifies known exploitable vulnerabilities. A CVE sitting in a library that never loads is not a compliance failure.

⚠️ Why That Distinction Changes Your Budget

If you chase every CVE, you will never finish, and you will spend money proving nothing. If you chase exploitable CVEs, the list gets small enough to defend in writing.

Edge Labs AI runs a "No Known Exploitable Vulnerabilities" check that produces the explanation an auditor asks for, rather than a raw count. I would rather hand over twelve justified findings than a spreadsheet of nine hundred, which is the whole premise of our exploitation-aware vulnerability management.

🔍 What "Exploitable" Means in Practice

Four signals, four different jobs. Use them together or you are guessing.

A CVSS-sorted queue cannot tell you when a legal clock starts. Only confirmed exploitation plus your own product context does that.

⏰ The Clock Trigger, Stated Plainly

Your 24-hour obligation begins when you become aware of an actively exploited vulnerability in your product. That is an exploitation question, not a severity question.

So build the join that answers it. Edge Labs AI measures this by correlating SBOM components against KEV and EPSS daily, then flagging which of those components are live in the running workload, and the CRA and NIS2 Compliance Center ties that flag to a named requirement ID.

📦 SBOM Is the Load-Bearing Artifact

An SBOM is a machine-readable list of what is inside your product. Generate it in CycloneDX or SPDX as a blocking step in your build pipeline.

Not weekly. Not on request. Every build, versioned, stored where you control it.

⚠️ The One-Level-Down Limit Nobody Mentions

Most SBOM practice and most supplier contracts only require components one level down. Your direct dependencies get listed. Their dependencies often do not.

That means a supplier SBOM frequently cannot answer "do I have a vulnerable component." You will need runtime observation to close that gap, because you cannot do this manually anymore. The scale is written into the law itself, and our field notes on container security vulnerabilities show what that gap looks like in practice.

❌ Scanning Without Enforcement Is a Placebo

A scan that produces a report nobody blocks on is theatre. A scan that fails the build is a control.

The difference is whether the result becomes a release decision. Multi-stage builds help too, since shipping only compiled output shrinks what an attacker can reach.

Across the runtime deployments Edge Labs AI has run, the pattern is consistent: the tool worked perfectly and the process failed. Something was installed and never given a policy.

✅ Runtime Evidence Behind a not_affected Claim

VEX (Vulnerability Exploitability eXchange) is how you state that a vulnerability does not affect your product. Every not_affected status needs a justification.

"The vulnerable function is not present" is stronger when you can show it never executed. Edge Labs AI uses eBPF, a Linux kernel technology that observes system calls without modifying the kernel, to record exactly that, which is the foundation of our workload and application security.

⚠️ The Honest Limit

Runtime evidence does not replace secure-by-design documentation. It proves what happened, not that you designed responsibly.

You still owe Annex I process evidence, threat modelling records, and update procedures. I have watched teams assume runtime telemetry covers all of it, and it does not.

🗣️ What Practitioners Are Saying

"Your SBOM is about to be a compliance document, not just a nice to have."
u/[poster], r/devsecops Reddit Thread

"Good IPS/IDS/EDR software. Webportal management is good. Docker container integration is useful." Dislike: "Description of issues can be complicated for non-technical folks."
Verified User in Computer Software EdgeLabs G2 - Verified Review

Edge Labs AI layers above the Falco ecosystem rather than replacing it, adding exploitation-aware scoring, response, and requirement-ID mapping on top of that same kernel-level signal. Falco showed the category what runtime evidence looks like, and we built on it rather than around it, as our review of open-source Kubernetes security tools explains.

Q6. How Do You Actually Survive the 24-Hour Reporting Clock?

Correlate your SBOM against CISA KEV and EPSS to detect exploitation, assemble an early warning within 24 hours, submit the full notification within 72 hours to the CSIRT of your main establishment through the Single Reporting Platform, then file the final report within 14 days of a corrective measure. Keep a locally timestamped evidence pack so the record exists regardless of platform availability.

⏰ The Five Steps, With Owners Attached

Assign a name to each step now. An unowned step at 2am on a Saturday is a missed deadline.

1. Detect (continuous). Join your SBOM component list against KEV and EPSS daily. Owner: whoever runs vulnerability management. Artifact: a dated match record.
2. Trigger (hour 0). Define the internal rule that turns a KEV match on a live component into an official awareness event. Owner: on-call security lead. Artifact: a timestamped awareness log entry.
3. Early warning (within 24h). File the initial notification with the CSIRT of your main establishment. Owner: named 24-hour reporting owner. Artifact: submission receipt.
4. Full notification (within 72h). Add affected versions, corrective measures taken, and impact detail. Owner: same. Artifact: the complete notification record.
5. Final report (within 14 days of a fix). Describe the vulnerability, the fix, and the mitigation guidance. Owner: product engineering lead. Artifact: the closing report.

✅ Run a Dry Rehearsal Before September

Pick your highest-revenue product and walk the whole thing end to end this month. Time it.

Edge Labs AI generates detection and response records on the agent itself, so the timestamped evidence needed at step three exists locally even in disconnected or air-gapped deployments. That matters because step three is where most teams discover they have no record of when they became aware, and how the agent works is worth understanding before you rehearse.

📄 The CVD Policy Most SMB Toolchains Are Missing

A coordinated vulnerability disclosure policy tells outside researchers how to report a flaw to you. It becomes operative from September 2026.

It is a page of text and a monitored inbox. Most small teams simply have not written it, and it is the cheapest requirement on the entire list.

⚠️ Plan for the Platform Not Being There

Here is the uncomfortable part. As of 29 June 2026, ENISA's Single Reporting Platform was not yet live, with reporting duties starting 11 September 2026. ENISA has it scheduled to be operational by that date, with a testing period expected beforehand.

Your 24-hour clock starts anyway. So somebody will try to file a report on 12 September using a portal they first saw on 11 September.

💾 Build an Offline Evidence Pack

Create a template you control, stored under your own systems. It should hold five things.

• Timestamps: when you became aware, and how you know.
• Exploitation evidence: the KEV or EPSS record, plus what you observed running.
• Affected versions: exact, not approximate.
• Mitigation status: what you did, and when.
• Distribution scope: who has the affected versions.

I have seen a production database and every backup deleted in a single API call, gone in nine seconds. That is faster than you can read a Slack message, which is the whole argument for evidence that lives where the workload lives, and the same argument behind our AI-generated response playbooks.

🔐 Three Questions for Every Vendor

Ask these before you sign anything. The answers separate real capability from marketing.

• Where are my SBOM and vulnerability telemetry stored, and under whose jurisdiction?
• Does detection continue with no cloud backend reachable?
• Does response continue too, or only detection?

Edge Labs AI answers the second and third with yes, since detection and response both execute on the agent, with host-local in-line blocking configurable from one minute to 90 days. We built it that way for air-gapped customers, and it turned into a compliance feature by accident. Our oil and gas edge deployment is where that design got tested hardest.

🔄 One Pipeline, Two Regulations

CRA reporting is single-entry to the CSIRT of your main establishment, with information shared onward to ENISA and other affected CSIRTs. That naturally overlaps NIS2 incident duties.

A delegated regulation adopted 11 December 2025 sets the conditions for delaying CSIRT-to-CSIRT dissemination on security grounds. Build one evidence pipeline that can emit both notification formats, and stop maintaining two. Our piece on why NIS2 and CRA change the game for edge AI security works through that overlap.

"With the EU Cyber Resilience Act deadline getting closer, I'm curious how others are approaching this in practice."
u/[poster], r/cybersecurity Reddit Thread

Q7. Where Do LLM Agents and MCP Servers Fit, and What Should You Put in Place First?

If you ship software embedding an LLM, agent framework, or MCP server, it is a product with digital elements and sits in CRA scope. Model and agent components belong in your inventory, and agent-layer exploitation (prompt injection, tool poisoning, an over-permissioned tool call) is a reportable security event. Buy in deadline order: detection and reporting before September 2026, documentation before December 2027.

🤖 AI Products Are Not a Separate Category

The CRA covers products with digital elements. It does not carve out AI.

So an agent framework you ship, an MCP server you expose, or a model you bundle all sit inside scope. Nobody writing CRA tool listicles has said this out loud yet, which is odd given how much software now embeds a model. Our guide to AI workload security covers the ground the listicles skip.

⚠️ You Cannot Govern What You Do Not Know Exists

Most teams cannot list their agents. Models get pulled, tools get registered, and MCP servers appear in a sprint nobody documented.

Edge Labs AI's read is that inventory comes before policy here, because an unlisted agent is an unlisted component in your SBOM. Start by asking what is actually running, not what your architecture diagram claims, which is exactly the point of AI agent governance.

🔒 The Two-of-Three Permission Rule

Agents typically want three powers: read your files, reach the network, and execute code. Grant any two, not all three.

All three together means an agent can read a secret, write a payload, and send it out. That is not a hypothetical; it is the plain arithmetic of the permissions.

✅ Use Deterministic Hooks, Not Instructions

A prompt is a suggestion. A hook is code that runs whether the model likes it or not.

OWASP names excessive agency as a top LLM risk precisely because instructions do not constrain behavior reliably. I once watched an agent report that it had violated every principle it was given, then explain that it guessed instead of verifying. You can patch a bug, but you cannot patch a brain. Our writeup on MCP security best practices sets out what enforceable constraints look like.

📣 What a Reportable Agent Incident Looks Like

Three concrete shapes, all of which are security events, not quirks.

• Prompt injection reaching a tool. Untrusted input causes the agent to call a tool with attacker-chosen arguments, which our explainer on prompt injection attacks breaks down.
• MCP tool poisoning. A registered tool's description or behavior is altered to redirect agent actions.
• Over-permissioned action. The agent writes to production or exfiltrates data it should never have reached.

If any of those hits a product you placed on the EU market, treat it as reportable and start the clock. Edge Labs AI's Parallax engine handles this at runtime through an LLM proxy doing input and output alignment, prompt-injection and tool-poisoning defense, and hallucination checks.

🧭 Buy in Deadline Order, Not Feature Order

Three common situations, three different sequences.

💰 The Cheapest Order of Operations

Shrink the problem first with hardened base images. Then enforce in CI. Then detect at runtime. Then document.

Doing it backwards means paying to triage findings you could have deleted. Momentum is the only authority here, so ship the smallest working version of each step, and our practical CRA roadmap sequences those steps for you.

❌ Where Edge Labs AI Is the Wrong Answer

Edge Labs AI's Compliance Center covers runtime, vulnerability-handling, and detection-and-response controls, and it does not cover business continuity, backup, MFA as a program, HR training, Annex VII authoring, or the CRA's 5- and 10-year support obligations. It also does not do OT visibility or IoT-hardware security, and no tool including ours confers CRA certification.

What I think shifts over the next two years is that distributed AI computing forces distributed security, and securing the LLM agent at runtime stops being a niche question. If your agents already hold all three permissions in production, I would genuinely like to hear how you are constraining them, because I do not think the category has settled this yet. If you want to work through it with us, get in touch.

FAQs

What are CRA compliance tools, and what do they actually do?

CRA compliance tools help manufacturers of products with digital elements meet Regulation (EU) 2024/2847 across scope and class assessment, Annex I gap analysis, SBOM generation, exploitation-aware vulnerability monitoring, VEX justification, Annex VII documentation, and the 24h, 72h, and 14-day reporting workflow.

In practice, the category splits into four jobs, and we think most buying mistakes come from treating it as one purchase:

• Runtime evidence that answers what actually executed, not what was merely installed.
• Build-time scanning and hardened images that shrink the problem before anything ships.
• Compliance-evidence automation for attestation, policies, and control mapping.
• Reporting infrastructure that moves a notification to the right CSIRT inside the deadline.

The ones worth paying for produce timestamped, exportable artifacts rather than dashboards that expire with your subscription. Edge Labs AI ships a CRA and NIS2 Compliance Center that maps each runtime control to a named requirement ID, including the Annex I "No Known Exploitable Vulnerabilities" check, so the 2027 technical file assembles from live evidence. What no tool does, including ours, is confer compliance. Conformity sits permanently with the manufacturer.

How should we evaluate a CRA compliance tool before buying it?

Score every candidate one to five on five criteria. An SMB buyer with no GRC function can finish this in an afternoon.

• Requirement-ID mapping depth. Does a control you run link to a named CRA article or Annex clause? Without that link, an auditor gets a dashboard and a story instead of evidence.
• Exploited-vulnerability and explainability scoring. CVSS gives severity, EPSS gives exploitation probability, CISA KEV confirms exploitation in the wild, and CWE names the weakness class. You need all four, because the CRA trigger is active exploitation.
• Runtime enforcement evidence. Can it show what executed, or only what was present at build time?
• SBOM coverage, build and runtime. Does it emit CycloneDX or SPDX from CI and also know which components loaded in production?
• Deployment and data reach. Does it generate evidence with no egress, and under whose jurisdiction does your SBOM data live?

Edge Labs AI weights the exploitability criterion highest, because CVSS-first patching quietly consumes most of a small team's remediation time. Add one informal sixth test after week one of any trial: does the tool tell you when it is not actually enforcing anything? Across the runtime deployments we run, something is misconfigured essentially every time we look.

Do CRA compliance tools remove the need to fix every CVE?

No, and the opposite reading costs teams entire quarters. The Commission's own Q&A clarifies that manufacturers must ship without known exploitable vulnerabilities, not without all vulnerabilities. A CVE sitting in a library that never loads is not a compliance failure.

That distinction changes your budget. If you chase every CVE, you will never finish and you will spend money proving nothing. If you chase exploitable CVEs, the list becomes small enough to defend in writing.

Proving it takes three moving parts:

• A versioned SBOM emitted as a blocking step in every build, in CycloneDX or SPDX.
• A daily correlation of those components against CISA KEV and EPSS.
• Runtime observation showing whether the vulnerable code path ever executed, which is what makes a VEX not_affected justification defensible.

Edge Labs AI records observed execution at the kernel level using eBPF, then explains why a finding is exploitable in the running workload rather than handing over a raw count. Our approach to exploitation-aware vulnerability management exists because we would rather submit twelve justified findings than a spreadsheet of nine hundred. Runtime evidence still does not replace secure-by-design documentation, threat modelling records, or update procedures.

Which CRA deadlines do we need tooling in place for, and in what order?

Three dates matter, and they do not carry equal urgency for tooling.

• 11 September 2026. Reporting duties begin. Actively exploited vulnerabilities and severe incidents require an early warning within 24 hours, a full notification within 72 hours, and a final report within 14 days of a corrective measure, including for products already on the market.
• 11 December 2026. Member States designate notified bodies, which matters if any product is Annex III Class II or Annex IV critical.
• 11 December 2027. Annex I requirements, the Annex VII technical file, and CE marking apply in full.

So buy in deadline order, not feature order: detection and reporting before September 2026, governance and documentation automation before December 2027. Documentation can be written late, whereas an exploitation event cannot be detected late.

Legacy products are the trap. Transitional arrangements let products placed on the market before December 2027 stay available without full conformity assessment, but they do not touch reporting, so something you shipped in 2019 still generates a 24-hour obligation. Edge Labs AI sees this gap most often in long-lived deployments, which is why our practical CRA readiness roadmap starts with detection rather than paperwork.

Do LLM agents and MCP servers fall under the CRA, and what should we secure first?

Yes. The CRA covers products with digital elements and carves out no exception for AI. An agent framework you ship, an MCP server you expose, or a model you bundle all sit inside scope, and those components belong in your inventory alongside every other dependency.

Agent-layer exploitation is a reportable security event, not a quirk. Three shapes recur:

• Prompt injection reaching a tool, where untrusted input causes a tool call with attacker-chosen arguments.
• MCP tool poisoning, where a registered tool's description or behavior is altered to redirect agent actions.
• Over-permissioned action, where the agent writes to production or exfiltrates data it should never have reached.

Start with inventory, because most teams cannot list their agents, and an unlisted agent is an unlisted component in your SBOM. Then constrain permissions: agents typically want to read files, reach the network, and execute code, so grant any two, never all three. Enforce with deterministic hooks rather than instructions, since a prompt is only a suggestion. Edge Labs AI handles this at runtime through the Parallax engine, whose AI and LLM security layer performs input and output alignment, prompt-injection and tool-poisoning defense, and hallucination checks.