Cyber Resilience Act testing turns product security evidence into compliance

At a glance

What this is: This article explains how the Cyber Resilience Act turns product-security testing into an evidence problem, with implications for LLM apps, MCP servers, web apps, and APIs.

Why it matters: It matters because IAM, NHI, and platform teams will need defensible test records where products depend on APIs, remote processing, tool permissions, and identity-linked access paths.

By the numbers:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.

👉 Read Equixly's analysis of CRA security testing for LLM apps, MCP servers, web apps, and APIs

Context

The core problem is not whether products can be tested, but whether manufacturers can prove that testing was effective, repeated, and tied to real product risk. Under the Cyber Resilience Act, that proof becomes part of compliance documentation, which means security testing is no longer just an engineering control, it is also a governance control for product assurance and market access. In identity-heavy systems, the question extends to access paths, secrets, tool permissions, and remote components that shape how software behaves in production.

The article’s focus on LLM apps, MCP servers, web apps, and APIs is relevant because these systems often depend on identity-adjacent controls such as service credentials, tool authorization, and remote processing boundaries. That makes them difficult to defend with a single annual test or a generic scan report. The compliance challenge is typical for modern software delivery, but the evidence burden is especially visible where runtime access and product functionality are tightly coupled.

For readers mapping this to identity governance, the important intersection is lifecycle evidence. If a product depends on secrets, tokens, or delegated tool access, then testing must show not only that vulnerabilities were found, but that access assumptions were validated and retested after change.

Key questions

Q: How should manufacturers prove that security testing under the CRA is effective?

A: They should link each test to a product risk, record what was tested, document what was not assessed, and keep retest evidence after fixes. The key is showing that the testing cadence is repeatable and explains why the product’s current security posture is defensible, not just that a scan or pentest happened once.

Q: Why do APIs and remote processing create CRA governance risk?

A: Because they may be part of the product’s actual function, not just supporting infrastructure. If a manufacturer depends on a remote service to deliver functionality, then the authorization model, change control, and test evidence for that path become part of the compliance story and cannot be treated as separate from the product.

Q: What breaks when security testing is not repeated after meaningful product changes?

A: The evidence chain breaks. Findings may no longer reflect the current attack surface, remediation may be stale, and compliance documentation can become misleading. For products that change quickly, especially those using APIs, model services, or delegated access, a stale test record is often weaker than no record at all.

Q: Which regulatory control area is most directly affected when testing evidence is weak?

A: Technical documentation and conformity assessment are the most immediate pressure points, because regulators may ask how the manufacturer tested the product, what changed since the last test, and whether identified issues were verified as fixed. Weak evidence also complicates incident and vulnerability reporting where proof of diligence matters.

Technical breakdown

What counts as effective and regular security testing under the CRA?

The CRA does not prescribe a single method such as penetration testing, vulnerability scanning, or code review. Instead, it requires manufacturers to apply effective and regular tests and reviews, then retain evidence in technical documentation. That means the organisation must be able to show that testing matches the product’s risk, is repeated after meaningful changes, and produces findings that can be assessed for exploitability and remediation status. A one-off pre-release test is usually not enough when the product continues to change after release.

Practical implication: build a repeatable testing policy that ties test frequency to product risk, release cadence, and security-relevant changes.

Why APIs and remote processing matter to CRA scope

A browser-only interface is not automatically the interesting object here. The CRA becomes more relevant where APIs or remote processing are part of the product’s function, because those components can carry the security posture of the product itself. If a remote service is required for the product to work, then its exposure, authorization model, and change control become part of the manufacturer’s security evidence. This is where identity and access decisions matter, especially for service accounts, tokens, and delegated tool use.

Practical implication: map each API and remote dependency to the product function it supports, then test the controls that protect that path.

How testing evidence supports conformity assessment and incident reporting

The CRA connects testing to documentation and reporting. Findings are not enough on their own. Manufacturers need records of what was tested, what was left unassessed, what changed, and whether fixes were verified. That evidence helps both the conformity assessment process and later incident or vulnerability reporting obligations. In practice, security testing becomes a traceability exercise: from test case to finding, from finding to fix, and from fix to retest. That is especially important for products with frequent releases or third-party integrations.

Practical implication: store test results, remediation notes, and retest proof in a form that can support both compliance review and regulatory reporting.

Threat narrative

Attacker objective: The attacker objective is to exploit product weaknesses before the manufacturer can detect, verify, and document them, increasing the chance of persistence or compliance failure.

1. Entry occurs through exposed product surfaces such as APIs, web interfaces, or remote processing components that have not been tested against realistic attack paths.
2. Escalation follows when weak authorization, unscoped tool permissions, or unverified remediation allows the attacker to move from reconnaissance into exploitable access.
3. Impact is the discovery of vulnerabilities that are both exploitable and undocumented, leaving the manufacturer unable to prove security testing coverage or remediation diligence.

NHI Mgmt Group analysis

Evidence quality is now a compliance control, not a post-release luxury. The CRA shifts security testing from an internal assurance task to a documentable obligation. Manufacturers need to show not only that they tested, but that the tests were meaningful, repeated, and tied to product risk. That raises the bar for engineering teams and compliance teams alike, because a finding without context is not defensible evidence. The practical conclusion is that test artefacts must be preserved with the same discipline as release records.

MCP server security exposes a broader identity governance gap in product testing. Where products depend on tool permissions, tokens, or secrets, security testing is also validating non-human identity assumptions. A product can pass functional testing and still fail governance if its access scoping is too broad or its credential model is undocumented. That makes NHI visibility part of CRA readiness, especially for LLM apps and agentic workflows. Practitioners should treat access scope as a testable security property, not an implementation detail.

Remote processing creates the new testing boundary that teams keep underestimating. The CRA does not stop at the visible user interface. If functionality depends on a hosted backend, API, or model service, then those components belong in the security evidence chain. This matters because modern products are often assembled from multiple runtime dependencies that change faster than formal documentation. The practical conclusion is that teams need product-scoped testing that follows the runtime path, not just the codebase.

Defensible cadence is the real governance concept here. The article points to a named concept we can call compliance-grade test cadence, meaning a testing rhythm that is justified by product risk, change events, and evidence retention. That concept matters because fixed intervals alone will not satisfy regulators if the product changes weekly. The right question is whether the cadence can survive scrutiny from a market surveillance authority. Practitioners should make the cadence explainable, not merely scheduled.

What this signals

Compliance-grade test cadence: manufacturers will need a testing rhythm that is justified by risk, not by calendar habit. That means product teams, security teams, and legal reviewers should agree on what events retrigger testing, what evidence must be retained, and how fast fixes must be retested. Where identity controls are involved, the same cadence should cover secrets, service accounts, and tool permissions, not just code paths.

For teams working with LLM apps and MCP servers, the governance question is shifting from whether a product was tested to whether its access model was tested. When tool permissions are broad or undocumented, the security evidence is weak even if vulnerability findings look clean. Practitioners can use the OWASP Agentic AI Top 10 and OWASP Agentic Applications Top 10 as a reference point for where agentic and identity-linked risk tends to surface.

The practical signal for security leaders is that CRA readiness now overlaps with identity lifecycle discipline. If secrets, tokens, and delegated access are not inventoried and retested after change, product security evidence will age out faster than compliance teams expect. That is why lifecycle visibility matters as much as test coverage in modern software programmes.

For practitioners

• Define a product-scoped testing policy Tie test frequency to product risk, release cadence, and security-relevant changes such as authentication updates, new APIs, and remote processing dependencies.
• Preserve evidence from test to retest Keep the original finding, severity or exploitability assessment, remediation record, and verification evidence together so they can support CRA technical documentation.
• Map identity-dependent components into the testing scope Include service accounts, tokens, tool permissions, and hosted backends in the test plan wherever the product function relies on them.
• Retest after changes that alter attack surface Trigger additional security testing after new authentication flows, significant API changes, model provider changes, or third-party tool integrations.
• Document scope decisions and exclusions Record why a browser-only interface, open-source component, or remote processing dependency is in or out of CRA scope so the decision is auditable.

Key takeaways

• The CRA turns security testing into auditable evidence, so a finding only matters if the manufacturer can show what was tested, fixed, and retested.
• LLM apps, MCP servers, APIs, and remote processing create identity-linked compliance risk because access scope and authorization are part of the product security story.
• The most defensible programmes will tie testing cadence to product risk and change events, then preserve evidence that can survive regulatory scrutiny.

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.
• 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.
• Conformity assessment: A conformity assessment is the formal process used to show that a high-risk AI system meets the obligations required before it is placed on the market. It combines documentation review, technical verification, and evidence of operational controls, rather than relying on policy statements alone.

What's in the full article

Equixly's full blog post covers the operational detail this post intentionally leaves for the source:

• Exact interpretation of CRA scope for LLM apps, MCP servers, browser-only web apps, and APIs
• How Equixly positions continuous penetration testing as evidence for repeatable compliance records
• Examples of findings, retest records, and remediation proof that can support CRA technical documentation
• The article's step-by-step explanation of how testing cadence should follow product risk and change events

👉 Equixly's full post covers the CRA testing cadence, evidence expectations, and scope decisions in more operational detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, workload identity, and agentic AI identity. It helps security and identity practitioners connect lifecycle controls to the wider governance models their programmes depend on.