Topic starter
21/08/2026 4:43 pm
TL;DR: Regular security testing now has to stand up as compliance evidence for products under the Cyber Resilience Act, according to Equixly. Product records now need to show what was tested, what changed, and how fixes were verified.
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: 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.
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.
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.
Glossary terms: Effective And Regular Tests, Technical Documentation, Product with digital elements, Remediation Verification
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 1 week ago by NHI Mgmt Group
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 pushes testing evidence into compliance proof
This post was modified 1 week ago by NHI Mgmt Group