Cyber Resilience Act testing turns product security evidence into compliance

At a glance

What this is: Equixly frames the Cyber Resilience Act as a testing-and-evidence problem, where manufacturers must prove effective and regular security testing rather than rely on a single pre-release scan.

Why it matters: This matters because security and identity teams need evidence that maps product risk, API exposure, and remote processing back to a repeatable testing cadence that can survive compliance scrutiny.

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.

Context

The Cyber Resilience Act is not just a product-scope regime. Its practical burden is evidence: manufacturers have to show that security testing happened, that it was repeated when product risk changed, and that findings were verified after remediation. That shifts compliance from isolated assessments to a durable testing record.

For identity and access practitioners, the relevance sits in the way modern products depend on APIs, remote processing, and machine-to-machine access. If those interfaces support an in-scope product’s function, they become part of the security evidence story, not just a technical implementation detail.

The article also reflects a broader regulatory pattern: compliance teams increasingly need test artefacts that can survive market surveillance, procurement, and incident review. A one-off scan may still find issues, but it will not by itself satisfy the question the CRA now asks: can you defend the cadence and the proof?

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. Once authentication, APIs, third-party components, or remote processing change, the old result stops being reliable evidence. The gap is not just technical risk. It is a compliance gap because the manufacturer loses traceability from finding to fix to verification.

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. Cadence matters when it reflects product risk, change velocity, and retesting after security-relevant modifications. If the organisation cannot explain why tests happened when they did, or why they were repeated after change, the evidence story weakens even if the product was once tested well.

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. That bundle shows the product was evaluated as a product, not just scanned as a snapshot. It also helps technical documentation answer the regulator’s core question: what was tested and what changed as a result?

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.

Technical breakdown

Why CRA testing becomes an evidence problem

The CRA does not prescribe a specific testing method, but it does require manufacturers to apply effective and regular tests and reviews, then keep reports in technical documentation. That means testing is only half the control. The other half is traceability: what was tested, what the result was, what could not be assessed, and whether a fix was verified. In practice, this pushes teams toward repeatable workflows rather than ad hoc assessments. Security evidence becomes part of conformity, not a separate engineering artefact.

Practical implication: Build testing records that tie findings to remediation and retest evidence, not just scan output.

How product scope reaches APIs, web apps, and remote processing

The CRA looks at whether a product with digital elements, including remote data processing, is part of the product’s function and whether the manufacturer designed it or is responsible for it. A browser-only web app is often outside scope on its own, but it can still matter when it supports an in-scope product. APIs, hosted back ends, and remote services become important because they may carry the security characteristics of the product itself. The scope test is therefore architectural, not just legal.

Practical implication: Map each exposed interface to the product function it supports before deciding what evidence belongs in scope.

Why cadence must track risk and product change

The CRA leaves ‘regular’ undefined, which means cadence has to be justified by product risk and change velocity. For fast-moving software, testing tied only to a calendar interval is hard to defend if authentication, authorization, model providers, or third-party components change in between assessments. The regulation’s logic is that the testing cycle should follow meaningful security change, not just a release calendar. That makes continuous or event-triggered testing easier to defend than a static annual routine when products evolve quickly.

Practical implication: Trigger additional testing after security-relevant changes instead of waiting for the next scheduled review.

Threat narrative

Attacker objective: The practical objective is not only exploitation, but also avoiding a defensible security record by exploiting changes that were never retested.

1. Entry occurs through the product surfaces that matter for CRA scope, including APIs, hosted back ends, LLM apps, and MCP servers when they support the product’s function.
2. Credential or exposure risk emerges when those interfaces are tested only once, because exploitable behaviour can reappear after changes to authentication, authorization, or third-party integrations.
3. Impact is compliance failure, because manufacturers may be unable to prove what was tested, what was fixed, and whether the fix was verified when regulators or customers ask for evidence.

Breaches seen in the wild

• Moltbook AI agent keys breach: Moltbook breach exposed 1.5M AI agent keys.
• LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

The named concept is compliance cadence debt. This is the gap between the product’s rate of change and the organisation’s ability to defend why its testing schedule still matches the risk. When authentication, authorisation, integrations, or remote processing change faster than the test plan, the compliance story weakens even if the latest scan is clean. The practical conclusion is that cadence must be tied to change events, not calendar comfort.

CRA and NIS2 are converging on the same procurement question. One regime governs the product, the other governs the organisation buying or operating it, but both demand better supply-chain evidence. That means product teams need to supply traceable test outputs, support-period clarity, and remediation proof that procurement and assurance teams can reuse. Practitioners should expect testing evidence to move from internal quality assurance into external trust documentation.

AI features do not create a separate compliance escape hatch. The article’s treatment of LLM apps and MCP servers is a useful reminder that the CRA still asks whether the software is part of an in-scope product and whether its remote processing supports a function. That keeps the burden on architecture and responsibility, not on branding a feature as AI. Teams should document where those components sit, who owns them, and what evidence proves their security testing.

Product security testing is now inseparable from proof of remediation. A finding list without retest evidence leaves a compliance gap because the CRA is interested in outcomes, not just detection. For practitioners, this means security validation, ticket closure, and technical documentation have to connect cleanly. The discipline that wins here is evidence continuity from discovery through fix verification.

From our research library:

• 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.
• Read next: Identity Security Regulatory Map

What this signals

Compliance cadence debt: product teams now have to prove that testing frequency still matches actual security change, not just a reporting calendar. That matters most where APIs, remote processing, and AI-enabled features evolve faster than the compliance review cycle.

Manufacturers that separate raw scan output from fix verification will struggle most under the CRA. The next operational question is not whether testing exists, but whether the evidence can survive procurement review, market surveillance, and incident scrutiny.

For practitioners

• 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.
• Separate compliance evidence from raw findings Store the test method, scope, results, and remediation status in a form that can be reused for conformity assessment and market-surveillance review.

Key takeaways

• The CRA turns security testing into a defensible evidence chain, not a one-time engineering task.
• The hardest part is no longer only finding issues, but proving what was tested, what changed, and how fixes were verified.
• Teams that tie testing cadence to product risk and change events will be better placed to defend compliance when scrutiny arrives.

Key terms

• Effective And Regular Tests: Security testing that is repeated, risk-informed, and capable of producing evidence a third party can review. Under the CRA, the point is not a specific tool or frequency, but whether the manufacturer can demonstrate ongoing attention to product security and show what changed after findings were made.
• Technical Documentation: The evidence package that describes how an AI system was built, tested, and controlled. It typically includes architecture, training data provenance, performance results, known limitations, and monitoring plans, and it must be complete before assessment begins.
• Product with digital elements: A product with digital elements is any hardware or software product that contains or depends on digital components and is placed on the market. Under the CRA, the phrase matters because it determines whether security, documentation, and lifecycle obligations apply across development and maintenance.
• Remediation Verification: Remediation verification is the follow-up step that confirms a fix actually changed the security state and did not simply create new documentation. It is the difference between acknowledging a problem and proving that the exposure window has closed.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore the course if your programme needs stronger governance for machine identities, access, and security evidence.