A Cyber Resilience Act (CRA) market-surveillance request should be handled as a controlled evidence-response workflow, not as a request to send an undifferentiated archive of every security or compliance record the manufacturer holds. Article 13(22) requires manufacturers, upon a reasoned request from a market surveillance authority, to provide the information and documentation necessary to demonstrate conformity of the product and the manufacturer’s processes with the essential cybersecurity requirements in Annex I. It also requires cooperation with the authority on measures taken to eliminate cybersecurity risks posed by the product.
The practical task is therefore to connect the authority’s question to the exact product, release, requirement, process and evidence that answer it. A prepared manufacturer can retrieve a controlled evidence set and explain its scope. An unprepared one may have the right records spread across engineering, vulnerability-management, release, quality and compliance systems but still struggle to prove which records belong to the product under review.
The CRA’s main manufacturer obligations apply from 11 December 2027. Building the response process before that date gives product and compliance teams time to make evidence retrievable as part of normal lifecycle work rather than reconstructing it after an authority request arrives.
What a reasoned market-surveillance request changes
Article 13(22) is narrower than “provide everything”. The manufacturer must provide the information and documentation necessary to demonstrate conformity of the product with digital elements and the processes put in place by the manufacturer with the essential cybersecurity requirements in Annex I.
The Regulation also specifies practical delivery conditions: the information may be provided in paper or electronic form and must be in a language that can be easily understood by the requesting authority.
A request can therefore create two related workstreams:
- an evidence response, showing how the relevant product and processes satisfy the applicable CRA requirements; and
- technical cooperation, if the authority asks the manufacturer to support measures intended to eliminate cybersecurity risks posed by the product.
Do not assume that document delivery closes the matter. The evidence package may be the beginning of a technical evaluation, clarification cycle or corrective-action process.
First scope the authority’s question
The first control is request intake. Before collecting files, record what the authority is actually asking the manufacturer to demonstrate.
Capture at least:
- the requesting authority and official contact details;
- the legal basis and wording of the request;
- the product, model, variant, software version or release named in the request;
- the relevant time period or market-placement context;
- the Annex I requirement, cybersecurity risk, process or evidence area under review, if stated;
- the information or documentation explicitly requested;
- the requested format and language;
- the authority’s deadline or response window, if one is specified; and
- the internal owner responsible for coordinating the response.
Where the scope is ambiguous, clarification is safer than guessing. For example, a request concerning a vulnerability-handling process may relate to one product, a product family or the manufacturer’s common process. Those scopes can require different evidence.
A controlled intake record also prevents parallel teams from answering different interpretations of the same authority request.
Anchor the response to the exact product and release
Evidence is only useful when its product context is clear. A current risk assessment, SBOM or test report may be technically valid but still be the wrong evidence if it belongs to a later release than the one being reviewed.
Before assembling the response, establish the product baseline:
- manufacturer legal entity responsible for the product;
- product name and internal identifier;
- hardware or software variant where relevant;
- exact software, firmware or release version relevant to the request;
- intended purpose and operating context relevant to the assessed requirement;
- date or period when the product was placed on the market;
- support-period status; and
- identifiers for the technical-documentation baseline associated with that version.
If the authority’s request covers several releases, keep each release-specific evidence set explicit. Do not silently combine evidence from multiple versions into one “current” technical file.
Use Annex VII as an evidence map, not as a response script
Article 31 requires technical documentation to contain the relevant data and details about the means used to ensure that the product and manufacturer processes comply with Annex I. Annex VII defines the minimum categories that the technical documentation must cover, as applicable.
Those categories include product identification and description, design and development information, production and vulnerability-handling processes, the cybersecurity risk assessment, support-period reasoning, standards and technical solutions used, test reports, the EU declaration of conformity and, where applicable, the SBOM.
That makes Annex VII a useful map for finding evidence. It does not mean every market-surveillance response must reproduce the entire technical documentation package.
If the authority asks how one update mechanism satisfies an Annex I requirement, the response should identify the product baseline, applicable requirement, relevant risk reasoning, design evidence, verification results and supporting process records. Sending unrelated documents can make the response harder to review and can obscure which evidence actually supports the answer.
Build a request-specific evidence index
Create an evidence index for each authority request before preparing the final submission. The index should make it possible for a reviewer to move from the authority’s question to the supporting records without reconstructing the relationship manually.
For each response item, record:
- the authority’s request item or question;
- the relevant CRA requirement or evidence area;
- the affected product and release;
- the manufacturer’s concise answer or explanation;
- the supporting evidence record;
- the evidence version, revision or date;
- the source system or controlled repository;
- the responsible internal owner; and
- the attachment name, secure transfer reference or other submission identifier.
Where a record is superseded, preserve the version that was actually relied on for the product under review. A later revision can be supplied as additional context, but it should not silently replace the historical evidence.
Preserve provenance when evidence comes from multiple systems
CRA evidence rarely lives in one repository. A manufacturer may hold requirements in a compliance system, test results in CI/CD, vulnerability decisions in a security tool, change approvals in tickets, SBOMs in build outputs and release records elsewhere.
For authority responses, preserve enough provenance to show what each record is and where it came from. Depending on the record type, useful controls include:
- stable document or artifact identifiers;
- revision numbers or timestamps;
- exact product and release references;
- source-system identifiers;
- export timestamps;
- hashes or checksums where they are already part of the manufacturer’s evidence controls; and
- a record of who approved the evidence for submission.
The CRA does not require every response artifact to carry a hash merely because hashing can be useful operationally. The objective is to avoid ambiguity about which evidence was submitted and whether it corresponds to the assessed product state.
If data must be exported from a live system, preserve the export or snapshot used for the response rather than relying only on a mutable dashboard that may look different later.
Treat the SBOM as a scoped disclosure
The software bill of materials (SBOM) deserves specific handling. Annex VII includes the SBOM within vulnerability-handling documentation and provides that, where applicable, it is supplied following a reasoned request from a market surveillance authority when necessary for that authority to check compliance with Annex I.
Operationally, this means the response team should be able to retrieve the SBOM for the correct product and release. A current SBOM for version 4.2 does not answer a request about version 3.8 if dependencies changed between those releases.
Before submission, verify:
- product and release identity;
- SBOM generation date or release association;
- format and version;
- component scope and known limitations;
- relationship to the product baseline; and
- whether the supplied SBOM is the record used for the relevant conformity evidence.
Do not confuse disclosure to a market surveillance authority with public publication of the SBOM. The CRA provision here concerns access for market-surveillance purposes following a reasoned request where necessary to check compliance.
Separate legal facts, engineering evidence and explanation
A strong response makes three layers distinguishable:
- Regulatory requirement. Identify the CRA provision or Annex I requirement relevant to the authority’s question.
- Engineering evidence. Provide the records that demonstrate how the product or process addresses that requirement.
- Manufacturer explanation. Explain how the evidence relates to the exact product, release and decision under review.
Do not use a policy statement as a substitute for evidence that the policy was applied. Likewise, do not assume a test result explains why a requirement was applicable or which risk it addresses.
For example, a secure-update response may need the requirement mapping, architecture or design evidence, verification results, release controls and vulnerability-handling records. Each serves a different purpose in the evidence chain.
This separation also makes gaps visible before submission. If the response has a legal statement but no product-specific evidence, or evidence without a clear requirement link, the manufacturer can resolve the gap deliberately instead of hiding it inside a large document package.
Preserve the request-and-response chronology
Market-surveillance interactions can evolve. An authority may narrow or broaden the scope, ask supplementary questions, challenge a test result or request evidence for an additional release.
Maintain a chronology that records:
- receipt of the original request;
- scope interpretation and any clarification;
- internal assignment and approvals;
- evidence versions selected for the response;
- submission date and transfer method;
- questions or supplementary requests from the authority;
- corrected or additional submissions;
- technical cooperation or corrective actions requested; and
- the final internal closure decision when the interaction is complete.
Do not overwrite an earlier response when new evidence is submitted. Preserve what the authority actually received at each stage and why the response changed.
This record is useful both for auditability and for engineering continuity if the people handling the request change during a long-running evaluation.
Prepare for access to deeper technical data
Article 53 gives market surveillance authorities access, upon a reasoned request and where necessary to assess conformity, to data required to assess the design, development, production and vulnerability handling of products, including related internal documentation of the relevant economic operator.
That means a response process should be capable of moving beyond a polished compliance summary when the authority needs the underlying technical basis.
Prepare a controlled method for locating deeper evidence without defaulting to unrestricted access to unrelated systems. The manufacturer should be able to identify the records relevant to the assessed requirement, preserve their provenance and transfer them through an approved channel.
Be ready for the response to become a technical evaluation
Market surveillance is not limited to document checking. Under the CRA’s ex-post enforcement model, Member States monitor products placed on the EU market and can take corrective or restrictive measures where needed.
Article 54 provides a specific path where a market surveillance authority has sufficient reason to consider that a product, including its vulnerability handling, presents a significant cybersecurity risk. The authority carries out an evaluation of compliance, and economic operators must cooperate. If non-compliance is found, the authority can require appropriate corrective action, withdrawal or recall within a reasonable period commensurate with the nature of the risk.
A manufacturer should therefore connect the evidence-response workflow to existing vulnerability, incident, release and corrective-action processes. If the authority’s question reveals a real security or conformity issue, the team should not treat the response as a documentation-only exercise.
Keep the original authority request, technical evaluation, remediation decisions, verification evidence and any market action connected but distinct. This preserves why each step occurred and which evidence supported it.
Austria: verify the competent authority at the time of the request
The Austrian Federal Chancellery explains that the CRA requires Member States to establish market surveillance authorities that verify compliance with CRA obligations. Its current CRA information also states that further Austrian responsibilities are being defined as part of national implementation.
Manufacturers operating in Austria should therefore avoid hard-coding an assumed authority into internal procedures before national assignments are final. The response runbook should include a step to verify the requesting body and the current Austrian competence structure when a request arrives.
The Federal Chancellery’s CRA FAQ also reflects the Article 13(22) requirement: manufacturers cooperate with market surveillance authorities on measures to avert cybersecurity risks and provide information and documentation upon a reasoned request, independently of the support period.
Build a pre-request response runbook
A short operational runbook can remove most of the avoidable delay when the first request arrives.
Define in advance:
- one intake channel for authority communications;
- responsibility for verifying the authority and legal scope;
- ownership for product and release identification;
- an evidence index linked to the technical-documentation baseline;
- retrieval paths for risk assessments, requirements, SBOMs, vulnerability decisions, tests, release evidence and conformity records;
- translation or language support where required;
- legal and compliance review for the response scope;
- engineering review for technical accuracy;
- an approval step before submission;
- an approved secure transfer mechanism;
- retention of exactly what was submitted; and
- escalation into vulnerability, corrective-action or release-governance workflows when the request identifies a substantive risk.
Test the runbook against one released product. Choose a requirement and ask the team to reconstruct the response package as if an authority had requested it. The exercise will expose missing product identifiers, stale evidence links, inaccessible historical records and ownership gaps before they become part of a real authority interaction.
Make evidence retrieval part of lifecycle governance
The difficult part of a market-surveillance response is often not writing the cover letter. It is proving that the risk assessment, requirement decision, SBOM, test result, vulnerability record and release evidence all belong to the exact product state being reviewed.
AA-sec is designed around traceability between requirements, security evidence, decisions and exact product or lifecycle context. That can support the operational problem of keeping authority-response evidence connected across the lifecycle; AA-sec does not determine CRA conformity, replace legal analysis or decide what an authority is legally entitled to request.
Key takeaway
A CRA market-surveillance evidence request should be answered with a scoped, traceable evidence package tied to the exact product and release. Article 13(22) requires manufacturers to provide the information and documentation necessary to demonstrate Annex I conformity on a reasoned request and to cooperate on measures addressing cybersecurity risks.
The practical control is to prepare before the request arrives: maintain release-specific technical evidence, preserve provenance, build a request-specific evidence index, retain the submission chronology and connect the response process to technical remediation when necessary. That turns market-surveillance cooperation from an emergency document hunt into a controlled product-security workflow.
Official sources
- Regulation (EU) 2024/2847 — Cyber Resilience Act — EUR-Lex
- Cyber Resilience Act - Member States — European Commission
- Cyber Resilience Act - Manufacturers — European Commission
- Fragen und Antworten zur Cyberresilienz-Verordnung — Austrian Federal Chancellery