Article 52 Market surveillance: requirements and evidence

How Article 52 market surveillance changes enforcement of the CRA

Article 52 applies the market surveillance regulation, Regulation (EU) 2019/1020, to the Cyber Resilience Act, and it requires each Member State to designate one or more market surveillance authorities to enforce the rules. For a manufacturer, importer or distributor, this means the CRA is not checked by a single EU body in Brussels. A national authority in each market where a product is sold can pick up a product, ask questions about it and act on what it finds. Article 52 also extends this supervision to the obligations of open-source software stewards under Article 24, so the open-source community is not outside the reach of enforcement. The risk Article 52 addresses is simple to state. Products with weak security can reach users, businesses and critical services without anyone independently checking how they were designed, built and maintained. Market surveillance is the point where that gap gets closed. Authorities can look at a product that is already on the market, not only at what the manufacturer declared before release. That is why enforcement under the CRA depends on the same market-facing approach used across other EU product laws. The practical difficulty is that an authority can ask for internal material. Under Article 53, on reasoned request, it can obtain the data needed to assess design, development, production and vulnerability handling, including internal documentation. Files therefore have to exist before any request arrives, and they have to agree with each other: the risk assessment, the vulnerability handling records, the support period basis and the test reports should tell one consistent story. Manufacturers should confirm with their national authority, or with their own legal counsel, which authority covers their markets and what format it expects for document production.

Which products, operators and records fall within market surveillance

An authority's reach under Article 52 depends on a few scoping decisions made early: which products are in scope, who sits in the supply chain, and which products and records fall before or after the transition dates. Each card below is one decision and the effect it has on what an authority can examine and what your file must hold.

In-scope products the authority can check

Market surveillance applies to products with digital elements that fall within the regulation's scope. Before an inspection, confirm which of your products are in scope, and whether each is a default, important or critical product, because that classification sets the evidence an authority will expect. Keep a current product inventory with versions, so the authority's request can be matched to a specific product.

Manufacturers and their supply chain

Authorities can reach the manufacturer of a product, and the regulation reaches importers and distributors who place products on the EU market. Map who in your chain holds each role, because an authority may request documentation from whichever operator placed the product on the market. Store evidence in a form that an importer or distributor can retrieve and provide on request.

Anyone who substantially modifies a product

A party that substantially modifies a product may take on manufacturer obligations for that product. This can happen to integrators, customizers and firms that rebrand or re-release software. Record each modification, its date and its effect on the product's security properties, so you can show whether the modified product is treated as newly placed on the market.

Products placed on the market before the transition date

Products placed on the market before 11 December 2027 fall under the regulation only if they are substantially modified from that date. Document the release date of each product version still in use, and track every change that could count as substantial. Without that record, you cannot show which products sit under the transition rule.

Reporting records for legacy products

The Article 14 reporting obligations apply to all in-scope products whenever they were placed on the market, so older products are not exempt from reporting. An authority may examine how you received vulnerability reports, how you notified the CSIRT and ENISA, and how you informed users. Keep timestamps, decision logs and notification copies for every reportable event.

Vulnerability handling and design records

An authority acting under Article 53 may request the data needed to assess design, development, production and vulnerability handling, including internal documentation. Confirm where your risk assessments, test results, vulnerability tracking and build records are stored and who can produce them within a short window. Versioned repositories and clear access roles make these requests faster to answer.

How a market surveillance authority tests a manufacturer's file

This table compares four enforcement routes under the CRA: reasoned data requests, evaluation of significant-risk products, coordinated sweeps and annual reporting. Read each row as the authority's test, the evidence it asks the manufacturer to produce, and the gaps that tend to come up. The authority is the tester here, not an independent auditor, and the evidence it reviews is the manufacturer's own internal documentation.

Enforcement route	Evidence the authority requests	Common findings
Reasoned request for design, development, production and vulnerability handling data (Article 53)	Internal design and development records, production controls, and the vulnerability handling process documentation, including the economic operator's internal documents	Documentation exists but does not match how the product is actually built or patched, or records cannot be produced quickly on a reasoned request
Evaluation of a product presenting significant cybersecurity risk (Article 54)	Evidence of compliance with the essential requirements, the risk assessment behind them, and the operator's response to the authority's concerns	Risk assessment is generic or outdated, so the operator cannot show why its controls match the product's actual risk
Coordinated sweep of a product category, including purchases under a cover identity (Article 60)	Test results and product samples checked against the same requirements as every other product in the category, plus the operator's public documentation	Products on sale do not match the documentation supplied, or support information and update commitments are missing or inconsistent
Annual reporting of outcomes to the Commission (Article 52(13))	No direct manufacturer evidence; the authority records its own inspection, evaluation and corrective action outcomes	Manufacturers should expect their case records to feed national and EU-level statistics, so file quality matters beyond a single inquiry

How to prepare a response to an authority request

This sequence gets the file ready before a market surveillance authority asks for it. The output is a scoped product list, a document index, named owners with a request procedure, a rehearsed retrieval, and a review cycle that keeps everything current.

Confirm products and operators in scope
Start by listing every product with digital elements you place on the EU market or make available, and record your role for each one: manufacturer, importer, distributor, or steward of open-source software. Note whether each product was placed on the market before 11 December 2027, because that date determines whether the regulation applies to it at all and which reporting duties already reach it. Compare the list against the Article 52 and Article 53 scope with your counsel. The output is a signed-off scope register that names each product, its role, and its classification basis. You know this step is done when every product in the register has a documented reason for being in or out of scope.
Build an index of reachable documents
Article 53 lets an authority, on reasoned request, reach the data needed to assess design, development, production and vulnerability handling, including internal documentation. Map where that material lives today: source repositories, build pipelines, SBOMs, vulnerability records, risk assessments, test reports, the technical file and support-period statements. For each item, record the system of record, the owner, and whether it is current. Where you rely on a third-party component or cloud service, note the source of its evidence. The output is a document index with a location and owner for every entry. You know this step is done when a reviewer can trace each Annex I obligation to at least one indexed item.
Assign owners and an access procedure
Name one response owner who receives authority requests and coordinates the answer, plus a backup. Assign a technical owner for each index category, such as engineering for design records and the PSIRT lead for vulnerability handling. Write a short procedure covering how a request is logged, how its scope and stated reasons are checked, who approves disclosure, how confidential material is marked, and how the response is recorded. Set access so the response team can retrieve material without granting broad rights to the rest of the organization. The output is a named owner list and a written request procedure. You know this step is done when each index entry has an accountable person and the procedure has been read and accepted by them.
Rehearse a mock request against the file
Run a tabletop exercise in which the response owner receives an illustrative request for the design and vulnerability handling records of one product. Have each owner retrieve their items from the index, time the retrieval only as an internal measure, and note gaps, stale versions and items that sit with a person rather than a system. Review whether the response would show the document version that applied at the relevant time. Record every failure as an action with an owner. The output is a rehearsal report and a corrected index. You know this step is done when a complete response can be assembled from the index within the procedure without ad hoc searching.
Set a review cycle for the file
Schedule a recurring review of the scope register, the document index, the owner list and the request procedure. Add review triggers for events that change the file: a new product release, a substantial modification, a change in support period, a new third-party component, a vulnerability disclosure, or a change in an authority's guidance. Keep a change log so you can show what the file contained on any past date. The review cadence is your own decision, and you should confirm the timing with counsel and the authority guidance that applies to your products. The output is a documented review calendar with triggers and an audit trail. You know this step is done when the most recent review is recorded and every trigger has a named owner.

What evidence an authority can ask to see and how to keep it current

A market surveillance authority can request access to the data needed to assess design, development, production and vulnerability handling, including internal documentation. The six artifacts below are the records that answer those requests, and each one goes stale unless it is updated as the product changes.

Technical documentation and design records

The authority tests whether the file describes the product as it is actually built, including architecture, components, intended purpose and the standards applied. Keep the file tied to the current release, with dated revisions and a named owner who signs off changes to the design. Check that the description still matches the shipped product after each major change, especially where a component or hosting model has moved.

Vulnerability handling processes

An authority checks whether the written process for receiving, triaging, fixing and disclosing vulnerabilities is the one your teams follow in practice. Keep the procedure current with named roles, intake channels and the records each step produces. Review it after staffing changes, so the people listed in the document are the people who handle reports.

Test and risk assessment records

The authority looks for a risk assessment that drove the cybersecurity requirements chosen, and for test results that show those requirements were verified. Keep test reports linked to the release they cover, with the scope, date, tester and open findings. Re-run and re-record tests after significant changes, and note any finding that was accepted rather than fixed, with the reason.

Reporting records under Article 14

Reporting records show when actively exploited vulnerabilities and severe incidents were identified, notified and followed up. Keep a log that captures the timeline of each event, the notifications sent through the ENISA platform and the information given to users. Confirm with your counsel and the designated CSIRT how the record should be retained, since the regulation sets the duty but the internal retention period is your decision.

Supplier and component records

An authority can ask how third-party and open-source components were selected, checked and kept up to date. Maintain an inventory of components with versions, licenses, known vulnerabilities and the owner responsible for each one. Refresh the inventory on every release, and record why any component with an open issue remains in the product.

Version history showing what changed and when

The authority compares what was documented with what was released, so it needs a dated trail of changes to design, code, support periods and documents. Keep version control on the technical file and the vulnerability records, so any two versions can be compared and an earlier one restored. Make sure each release links to the documentation version it was assessed against.

What readiness for market surveillance costs and what drives it

This table compares the main cost components of preparing for a national market surveillance authority's inspection, request for data or evaluation, and marks each as one-time or recurring. Read the drivers column to see what raises effort, and the last column to see how to hold it down. No price is given for readiness work; a quote follows from written scope.

Cost component	One-time or recurring	What drives it	How to keep it down
Internal legal and compliance time to map the authority's powers to the file	One-time, then recurring when powers or guidance change	Number of product lines in scope, how many Member States you sell into, and whether internal documentation is held across several entities	Build one mapping of Article 53 and Article 54 requests to named file sections, and review it only when the Commission guidance or national practice changes
Engineering time to assemble and maintain documentation	Recurring with each release and each substantial modification	Number of products, release frequency, and how much design, development, production and vulnerability handling evidence is generated automatically	Generate evidence from build and ticketing systems where possible, and keep the technical file current per release instead of rebuilding it on request
Tooling for document control and version history	Recurring licence or hosting cost, plus one-time setup	Commercial licence fees for document management, number of users, and the retention period the authority could ask about	Self-hosted open-source wiki or documentation systems with built-in version history can avoid licence spend; confirm retention, access control and export needs against your own policy
External review or mock request exercises	Recurring, usually once per planning cycle or after material change	Product complexity, number of products tested, and whether an outside assessor or implementation partner runs the exercise	Ask for a fixed-scope exercise with written deliverables, limit it to the highest-risk products, and reuse the findings to close gaps
Cost of exposure under Article 64 maximums	Contingent, incurred only if a breach is found	Breach category: up to EUR 15 million or 2.5% of worldwide annual turnover for Annex I and Articles 13 and 14, up to EUR 10 million or 2% for other listed obligations, and up to EUR 5 million or 1% for incorrect or misleading information, whichever is higher (Article 64)	Keep documentation accurate and consistent, since misleading information carries its own tier, and treat authority requests for data as a formal process with a named owner

How self-hosted open-source tools keep the file ready for an authority

A market surveillance authority can ask for design records, vulnerability handling records and internal documentation on reasoned request. The tools below can hold and control those records inside your own environment, but they do not make a product conform, and each needs a fit check before you rely on it.

CISO Assistant for audits and assessments

CISO Assistant is licensed AGPL-3.0-only, so modifications you make and offer to users over a network must be made available under the same terms. Its framework library and audit workflows can track assessments, evidence and findings for the control frameworks your organization already uses, which helps you show an authority how your governance records are organized. Confirm with counsel whether the AGPL terms fit your distribution model, and confirm which frameworks the installed version actually includes before planning around them.

XWiki for versioned technical documentation

XWiki is licensed LGPL-2.1-or-later, which governs changes to XWiki itself and the terms for linking it into other software. Its version control keeps every change to a page with what changed, when and by whom, and lets users compare any two versions and roll back. That history is useful when an authority asks how a design document or vulnerability handling procedure looked at a given date. Check that the platform's retention and backup settings preserve that history for the full period you must keep records.

BookStack for controlled access to records

BookStack is licensed MIT, a permissive license that requires the copyright notice and license text to be kept with copies of the software. User abilities come from assigned roles, and you can override permissions per role at the shelf, book, chapter or page level. This lets you limit who can edit a technical file or view restricted incident material, and show an authority who had access. Test the role configuration with real access reviews, because overrides at several levels can be hard to read back later.

Confirm fit before relying on them

None of these tools decides whether a product meets the regulation, and none is a substitute for the manufacturer's own technical documentation, risk assessment or vulnerability handling process. Before you depend on any of them, confirm the license obligations with counsel, check that the version you deploy has the features you need, and decide who owns each record and its retention. Where a tool is part of an implementation, the platform owner and the compliance lead should agree on that ownership in writing.

Who owns the response, who can help, and where the authority's role stops

The economic operator, meaning the manufacturer or whoever places the product on the EU market, owns the product, its technical documentation and every answer given to a market surveillance authority. Under Article 53, an authority with a reasoned request can require access to the data needed to assess design, development, production and vulnerability handling, including internal documentation. That access request lands on the operator, so the operator needs people who know where the records are and who is allowed to release them.

Named response owner: One accountable person, usually in product security or legal, receives requests and decides what is released.
Documentation custody: The operator holds the technical file, risk assessment, vulnerability handling records and test reports, and must be able to produce them without rebuilding them.
Authority contact routing: Staff at the national authority's contact points should be known in advance, with a rule for who replies and within what internal approval chain.
Corrective action decisions: Recalls, withdrawals and corrective measures under Article 54 are business and legal decisions the operator makes, with engineering input.
Coordination with other regulators: Overlapping duties under other EU laws may reach the same records, so one document set should serve all requests.

Check whether your internal response procedure has been rehearsed against a realistic request before an authority sends one.

Where organizations fall short when an authority comes knocking

When a market surveillance authority opens a case, the gaps it finds are usually organizational rather than technical: knowledge that sits with individuals, unclear ownership, and records that cannot be produced on request. Each card below names one gap, what it looks like under Article 52 and the fix to put in place before an authority asks.

Documentation held in people's heads

Design decisions, threat assumptions and vulnerability handling steps often live in the memory of a few engineers. Under Article 53 an authority can request the design, development and vulnerability handling records, and a verbal explanation does not satisfy a written request. Fix it by writing down each decision in a controlled repository, naming who maintains it, and checking that a colleague who did not write it can locate and explain it within a day.

No owner for reasoned requests

A reasoned request from an authority can arrive at a sales mailbox, a support queue or a personal address. Article 53 access requests are time-bound in practice, and delay or incomplete answers can themselves become a compliance finding. Fix it by naming a single accountable contact for authority requests, documenting the escalation path to legal and engineering, and running a tabletop exercise that sends a mock request through the whole path.

Version history that cannot show changes

An authority may ask what a product looked like on a given date and what changed before a vulnerability was fixed. If your change history only shows that a file was modified, you cannot answer those questions with confidence. Fix it by using version control for code, documentation and release records, so each change can be traced to a date, an author and a reason, and past releases can be reproduced.

Missing supplier and component records

Authorities assessing a product will ask which third-party and open-source components it contains, which versions are shipped and who supplies them. Records gathered only at audit time are often incomplete. Fix it by keeping a current inventory of components and their versions for every released product, linked to the vulnerability sources you monitor and to the supplier due diligence you performed.

Reporting records lost for products already on the market

Article 14 reporting duties apply to in-scope products whenever they were placed on the market, so records of actively exploited vulnerabilities and severe incidents for older products matter from 11 September 2026. Teams often archive notifications inconsistently or discard them after a patch ships. Fix it by retaining each report, its acknowledgement and the follow-up actions for the full support period of each product.

No tested process for corrective measures

Under Article 54 an authority can require corrective action, withdrawal or recall, and take provisional measures if an operator does not act. Organizations that have never walked through these steps lose time deciding who can stop distribution, which customers must be told and how updates reach installed products. Fix it by writing a corrective action procedure, assigning decision rights in advance and rehearsing a recall on a non-production product.

What buyers ask about Article 52 before hiring help

What does it cost to be ready for market surveillance, and what drives the cost?

No price is fixed by the regulation, so the cost depends on your product, your existing documentation and how much evidence you must produce. The main cost drivers are the number of products in scope, how mature your secure development and vulnerability handling records already are, the size of your software bill of materials and how quickly you need access to historic design records. Costs fall into two groups. One-time work includes gathering and organizing technical documentation, mapping evidence to Annex I, and building a retrieval process. Recurring work includes keeping documentation current after each release and responding to authority requests. When you request a quote from a partner, ask for the scope in writing, the deliverables, who prepares what, and which items you must supply yourself. Confirm with your legal team which internal records you may be asked to produce.

How long does preparation take, and what should our team be able to produce?

Preparation time depends on how much of your evidence already exists and how many products you place on the EU market. Confirm the timeline against your own environment rather than a generic estimate. Your team should be able to produce, on reasoned request, the design and development records, the production controls, and the vulnerability handling process for each product, including how it is applied across the support period. Authorities may request internal documentation, so the material must be retrievable quickly and in a consistent structure. A practical readiness check is to pick one product and time how long it takes to assemble its file from source. Document owners, storage locations and version history should be named before any request arrives. Confirm the expected format and response windows with the national authority or your legal counsel, since these are not set out in a single fixed template.

Can our own team handle market surveillance readiness without an outside partner?

Yes, in many organizations an internal team can prepare for market surveillance, provided it has clear ownership and enough security and product knowledge. Ownership stays with you in every case. A partner can help set up the systems, controls and evidence collection, but only an independent auditor, assessor or certification body issues reports or certificates. Internal teams often struggle with three areas: consistent version control of documentation, traceability between vulnerabilities and fixes, and testing evidence that a reviewer can follow without the original engineers. Consider outside help if these gaps are large, if several product lines share components, or if your staff are already committed to releases. Whatever you decide, document the roles in writing, so the person named for responding to an authority knows what to produce.

Can a partner represent us to the market surveillance authority?

Representation depends on national law and the terms of your engagement, so confirm it with your legal team before you rely on it. As a rule, the economic operator remains responsible for its products and for answering the authority. DeployOpen prepares systems, controls and evidence, and it does not act as a regulator, auditor or certification body. Your contract should state who receives authority correspondence, who is authorized to respond, and how quickly your team must be informed. If a partner supports technical responses, agree in advance which facts it may confirm and which decisions remain with your management. Ask the authority or your national contact point whether a designated representative is required or accepted for your type of product.

What happens if an authority finds a product presents significant cybersecurity risk?

The authority first evaluates whether the product complies, and if it finds a significant cybersecurity risk, it may require corrective action, withdrawal or recall. If the operator does not act, the authority can take provisional measures. Your response plan should cover who evaluates the finding, how fast you can produce the relevant documentation, which corrective fixes are feasible, and how customers and distributors are informed. Prepare this before an incident, because the timing is driven by the authority's process. Confirm the specific powers, appeal routes and deadlines with your legal counsel and the relevant national authority, since they vary by Member State and product type.

How do open-source components affect what the authority can ask us for?

Open-source components do not remove your obligations for the products you place on the market. The authority can request access to the data needed to assess design, development, production and vulnerability handling, which covers how you select, track and update third-party components. Your records should show which open-source packages a product contains, who is responsible for monitoring their vulnerabilities, and how fixes reach users. Stewards of open-source software have a separate regime, and market surveillance authorities supervise their obligations under Article 24. Confirm with counsel whether your project or company is a manufacturer, a steward, or both, since the answer changes which records you must keep.

How DeployOpen prepares the file for an authority request

When a market surveillance authority asks for data under Article 53, the manufacturer must answer with accurate, organized records of how the product was designed, built, maintained and handled when vulnerabilities appeared. DeployOpen helps manufacturers and platform teams put those records in place inside their own infrastructure, before any request arrives, so the file reflects how the product is actually run.

How we scope

Agree in writing which products, platforms and internal documents fall inside the Article 52 preparation scope.
Map which records an authority could request for design, development, production and vulnerability handling.
Confirm with your counsel which Member State authority is likely to be responsible for each product line.

How we build

Configure self-hosted open-source platforms in your own cloud, data center or air-gapped network to hold controlled records.
Set up version history and role-based access so every document change shows who made it and when.
Test that a defined set of records can be retrieved and exported within the time your internal process allows.

How we hand over

Deliver a documented index of requestable records, with owners, storage locations and retention settings.
Provide a written runbook for receiving a reasoned request, logging it and routing it to legal and security staff.
Train the named response team on the runbook and record the training as evidence.

How we support

Offer ongoing support, upgrades and periodic reviews of the file as products and standards change, through a retainer.
Help your team rehearse a simulated authority request as an exercise, using an illustrative product scenario.
Confirm with your legal team how confidentiality and handling of internal documentation apply to each request.