Topic starter
21/08/2026 4:43 pm
TL;DR: The Cyber Resilience Act makes effective and regular security testing a defensible compliance requirement, and Equixly argues that manufacturers need repeatable evidence for LLM apps, MCP servers, web apps, and APIs, not just one-off scans. The compliance burden now sits on testing cadence, remediation proof, and product-scoped documentation rather than on a single method.
Editorial analysis by NHI Mgmt Group, based on content published by Equixly: “The Cyber Resilience Act and the key role of security testing”.
By the numbers:
- The Cyber Resilience Act entered into force on 10 December 2024 and its requirements apply progressively.
- From 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe security incidents within 24 hours, 72 hours, 14 days, or one month depending on the case.
- The European Commission approved its CRA implementation guidance on 27 July 2026, and the guidance includes 67 worked examples and five flowcharts.
Key questions
Q: What breaks when CRA testing is only done once before release?
A: A one-off test cannot defend product security over time because the CRA expects effective and regular testing, not a single snapshot.
Q: Why does the CRA make testing cadence a compliance issue?
A: Because the regulation asks manufacturers to show ongoing security effort, not just a secure launch posture.
Q: What evidence should teams keep to defend product security testing under the CRA?
A: Keep the test scope, the method used, the findings, the severity or relevance of those findings, the remediation performed, and proof that the fix was retested.
Practitioner guidance
- Define a defensible CRA testing cadence Tie testing frequency to product risk, release velocity, and security-relevant changes instead of using a fixed calendar interval for every product.
- Map in-scope product boundaries Document which APIs, remote processing components, LLM features, and MCP servers are part of the product’s function and therefore need evidence.
- Require retest evidence after remediation Keep proof that identified issues were fixed and that the retest covered the same product path, not a narrower substitute path.
Bottom line: The CRA turns security testing into a defensible evidence chain, not a one-time engineering task.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
21/08/2026 5:03 pm
CRA security evidence has become a governance control, not just a test artefact. The article is correct to frame Annex I and Annex VII as a proof problem because regulators will not care only that testing happened, but that it was repeatable, explainable, and tied to conformity. That changes the operating model for product security and compliance teams, especially where APIs and remote services sit inside the product boundary. Practitioners should treat test records as regulatory evidence, not engineering leftovers.
A few things that frame the scale:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: How do security teams decide whether APIs or remote services belong in CRA evidence?
A: Use the product-function test. If the API or remote service is necessary for the product to perform its intended function and the manufacturer designed or maintains it, it belongs in the evidence story. Browser-only pages are different, but supporting back ends, integrations, and remote processing can still be in scope when they are part of the product’s behaviour.
👉 Read our full editorial: Cyber Resilience Act testing turns product security evidence into compliance