sota.io
2026-04-20·14 min read·

CRA Art.32: Market Surveillance Authorities — Powers, Obligations, and What Manufacturers Need to Know (Developer Guide 2026)

The Cyber Resilience Act creates obligations. Article 32 creates the enforcement mechanism.

While most CRA guidance focuses on what manufacturers must build and document, less attention goes to the regulatory machinery that will check whether they did it correctly. Market surveillance authorities (MSAs) are the national bodies that investigate products in the EU market, demand documentation, order recalls, and coordinate cross-border enforcement. Article 32 defines their specific powers and obligations under the CRA.

Understanding how MSAs operate under CRA Article 32 is not just a compliance curiosity. It shapes how you structure your technical documentation, how quickly you must respond to authority requests, what "cooperation" legally means, and what the worst-case enforcement scenario looks like for a product that fails post-market scrutiny.

This guide explains the MSA framework, how Article 32 fits into the broader EU market surveillance system, what specific powers authorities hold over products with digital elements, and what manufacturers need to do before an investigator knocks.

The EU Market Surveillance Framework and Where CRA Fits

Market surveillance of products in the EU operates under Regulation (EU) 2019/1020 — the Market Surveillance Regulation (MSR). The MSR establishes general rules: who does market surveillance, what powers they have, how they share information, and how they coordinate across member states.

The CRA builds on top of the MSR rather than creating a parallel system. This matters because:

CRA Article 32 identifies which national authorities are designated as MSAs for products with digital elements, specifies their CRA-specific obligations, and references the cooperation mechanisms they must use.

Which Authorities Are the CRA's MSAs?

Article 32(1) requires each member state to designate one or more market surveillance authorities for CRA purposes. This designation must happen before the CRA's enforcement dates.

The key insight is that CRA MSAs will likely overlap with existing national authorities from related sectors:

Cybersecurity authorities: Many member states are designating their national cybersecurity agencies (NCAs) — the NIS2 competent authorities — as CRA MSAs or co-MSAs. This makes organizational sense: these bodies already have technical capacity to assess cybersecurity controls.

Consumer product safety authorities: For products marketed to consumers, existing product safety MSAs may retain or share jurisdiction, particularly for connected devices that also fall under other safety regimes.

Sector regulators: Products in regulated sectors (medical devices with digital elements, industrial control systems, automotive components) may have sector-specific MSAs with CRA oversight layered on.

The practical implication for manufacturers: there may be multiple competent authorities depending on what you make and where you sell it. A connected medical device might face oversight from both the medical device regulator and a cybersecurity MSA. Understanding which authority covers your product category in your target markets is a pre-market task, not a post-incident reaction.

Core Powers of CRA Market Surveillance Authorities

Article 32 incorporates the full MSR toolkit and adds CRA-specific capabilities. For manufacturers, the relevant powers fall into four categories.

1. Documentation and Information Powers

MSAs can require manufacturers, importers, and distributors to provide:

Critically, MSAs can demand this documentation without first demonstrating that a product is non-compliant. Documentation requests are a routine surveillance tool, not only an investigation trigger. Some member states will conduct random documentation audits as standard practice.

Timeline: The MSR and CRA do not specify a single universal response deadline for documentation requests — the MSA sets the timeframe, which must be reasonable. In practice, national authorities typically allow 10–30 business days for comprehensive documentation packages. Building and maintaining current technical documentation from the start is the only way to respond within these windows without crisis-mode document assembly.

2. Physical Inspection and Testing Powers

MSAs can:

The source code inspection power deserves attention. Unlike traditional product safety regimes where inspectors examine physical components, CRA MSAs can examine software implementations. The legal conditions for compelling source code disclosure are narrow — MSAs must demonstrate necessity and maintain confidentiality obligations — but the power exists.

For manufacturers, this means: security-by-obscurity is not a compliance strategy under CRA. Technical documentation must be comprehensive enough that an MSA can assess compliance without requiring source code, but source code access remains a last-resort investigative tool.

3. Corrective and Restrictive Measures

When an MSA finds or suspects non-compliance, they can order:

Voluntary corrective action requests: First, authorities typically request that manufacturers take corrective action voluntarily — issue a security update, add warnings, withdraw a non-compliant batch.

Mandatory corrective orders: If voluntary action is insufficient, MSAs can issue binding orders requiring specific corrective measures within defined timeframes.

Restriction of availability: MSAs can order that a product not be made available on the market, or that availability be conditioned on corrections.

Withdrawal from the market: Products already distributed but not yet with end users can be required to be withdrawn from the distribution chain.

Recall: The strongest measure — requiring products already with end users to be recalled. CRA Article 32 gives MSAs explicit recall authority for products with digital elements that present a significant cybersecurity risk.

The "significant cybersecurity risk" threshold for recall is intentionally broad under the CRA. A product that contains exploitable vulnerabilities allowing unauthorized remote access to sensitive systems could meet this threshold even without evidence of active exploitation.

4. Emergency Powers

For products presenting an "immediate, serious risk" — defined as risks likely to result in severe harm without immediate action — MSAs can take emergency measures including:

MSA Obligations, Not Just Powers

Article 32 imposes obligations on MSAs as well as granting them powers. For manufacturers, these obligations are protective — they define the procedural safeguards that constrain how MSAs can act.

Proportionality

MSA measures must be proportionate to the nature and severity of the non-compliance. An authority cannot order a product recall in response to a documentation formatting issue. Corrective measures must match the risk level.

Manufacturer Notification

Before taking restrictive measures, MSAs must generally notify the economic operator (manufacturer, importer, or distributor) and provide an opportunity to respond. The exception is emergency measures where prior notification would prevent effective action.

Transparency and Reasoning

MSAs must document the reasons for their decisions. Manufacturers who receive MSA orders have the right to understand the legal basis, factual findings, and specific non-compliance identified.

Confidentiality

When MSAs access technical documentation — especially SBOMs, vulnerability records, or source code — they are bound by confidentiality obligations. Information obtained in market surveillance cannot be disclosed in ways that would damage the commercial interests of the manufacturer or harm the security of users (for example, by publishing vulnerability details before patches are available).

This confidentiality obligation is particularly significant for SBOMs. An SBOM discloses your full software supply chain. MSAs who receive SBOMs are legally bound not to disclose their contents in ways that create security or competitive risks.

Cross-Border Coordination

MSAs must cooperate with their counterparts in other member states through:

The CRA-Specific MSA Obligation: ENISA Coordination

Article 32 includes a CRA-specific requirement that distinguishes it from general market surveillance regimes: MSAs must coordinate with ENISA (the EU Agency for Cybersecurity) on cybersecurity matters.

This coordination happens through several mechanisms:

ENISA as technical expert: When MSAs lack internal technical capacity to assess complex cybersecurity claims, they can request ENISA's technical expertise. ENISA does not itself conduct market surveillance, but can provide assessments that inform MSA decisions.

Standardization interface: ENISA maintains relationships with European standardization bodies (CEN, CENELEC, ETSI) developing CRA-harmonized standards. When MSAs encounter compliance questions related to specific technical standards, ENISA is a channel for authoritative interpretation.

CERT network interface: ENISA coordinates the European network of CSIRTs (Computer Security Incident Response Teams). When a CRA product investigation intersects with a cybersecurity incident or active vulnerability exploitation, MSA findings may feed into the CSIRT network and vice versa.

Systemic risk identification: Multiple MSA investigations into similar product categories may surface systemic vulnerabilities — classes of products with structural cybersecurity weaknesses. ENISA aggregates this intelligence to inform future standardization and potentially trigger Commission-level action.

For manufacturers, this means that a serious CRA investigation into your product category is not siloed within one national authority. If your product class has a systemic security issue, ENISA may be involved — and the outcome may influence harmonized standards in ways that affect the entire sector.

What Triggers an MSA Investigation?

Understanding the triggers helps manufacturers assess their realistic investigation risk.

Reactive triggers:

Proactive triggers:

Manufacturer Obligations During an MSA Investigation

When an MSA initiates a CRA investigation involving your product, several legal obligations apply.

Cooperation Obligation

CRA and the MSR impose an affirmative cooperation obligation on economic operators. "Cooperation" means:

Documentation Provision

The CRA technical documentation package required by Annex VII must be producible on demand. You do not have to proactively submit documentation to the MSA before an investigation — but you must be able to produce it when asked.

This means the documentation must actually exist and be current. Documentation assembled retrospectively — after a product is on the market — often has gaps, inconsistencies, or dates that don't match the product's actual development timeline. MSAs are experienced at identifying documentation that was created for regulatory purposes rather than as part of genuine development process.

Authorized Representative Role

For manufacturers outside the EU, the CRA requires an authorized representative (EU-based). During an MSA investigation, the authorized representative is the primary contact point. Their legal obligation is to ensure the manufacturer cooperates — they cannot simply refuse to respond on the grounds that the manufacturer is non-EU.

For non-EU manufacturers using European authorized representatives, the practical implication is that your authorized representative needs to have actual authority to coordinate your response, not just a name on a form.

Self-Reporting During Investigations

If your own post-market monitoring or vulnerability handling process identifies a compliance issue during an MSA investigation, you generally must disclose it. Concealing known non-compliance from an active investigation is a separate and more serious violation than the original compliance failure.

Preparing for MSA Scrutiny: The Practical Checklist

Based on Article 32's powers and the audit patterns from analogous EU product safety regimes, here are the preparation steps that matter:

Documentation readiness:

Process evidence:

Contact and coordination:

Vulnerability response:

Python: CRA MSA Investigation Readiness Tracker

from dataclasses import dataclass, field
from typing import Optional
from datetime import date, timedelta

@dataclass
class MSAReadinessStatus:
    """Track CRA Article 32 market surveillance readiness."""
    product_name: str
    product_class: str  # "Class I", "Class I (default)", "Class II"

    # Documentation completeness
    technical_docs_complete: bool = False
    technical_docs_last_updated: Optional[date] = None
    sbom_current: bool = False
    sbom_format: Optional[str] = None  # e.g. "SPDX 2.3", "CycloneDX 1.6"
    doc_of_conformity_signed: bool = False
    conformity_assessment_documented: bool = False

    # Process documentation
    vuln_handling_procedure_documented: bool = False
    post_market_monitoring_recorded: bool = False
    security_testing_documented: bool = False

    # Organizational readiness
    eu_authorized_representative: Optional[str] = None
    msa_contact_person: Optional[str] = None
    internal_escalation_procedure: bool = False

    def readiness_score(self) -> tuple[int, int]:
        """Returns (score, max_score) for MSA investigation readiness."""
        checks = [
            self.technical_docs_complete,
            self.technical_docs_last_updated is not None and
                (date.today() - self.technical_docs_last_updated).days < 90,
            self.sbom_current,
            self.sbom_format is not None,
            self.doc_of_conformity_signed,
            self.conformity_assessment_documented,
            self.vuln_handling_procedure_documented,
            self.post_market_monitoring_recorded,
            self.security_testing_documented,
            self.eu_authorized_representative is not None,
            self.msa_contact_person is not None,
            self.internal_escalation_procedure,
        ]
        return sum(checks), len(checks)

    def gaps(self) -> list[str]:
        """Identify readiness gaps."""
        issues = []
        if not self.technical_docs_complete:
            issues.append("CRITICAL: Technical documentation (Annex VII) incomplete")
        if self.technical_docs_last_updated is None:
            issues.append("CRITICAL: Technical documentation has no last-updated date")
        elif (date.today() - self.technical_docs_last_updated).days >= 90:
            issues.append(f"HIGH: Technical documentation may be stale ({self.technical_docs_last_updated})")
        if not self.sbom_current:
            issues.append("CRITICAL: SBOM not current")
        if self.sbom_format is None:
            issues.append("HIGH: SBOM format not specified (use SPDX 2.3 or CycloneDX 1.6)")
        if not self.doc_of_conformity_signed:
            issues.append("CRITICAL: EU Declaration of Conformity not signed")
        if not self.conformity_assessment_documented:
            issues.append("CRITICAL: Conformity assessment procedure not documented")
        if not self.vuln_handling_procedure_documented:
            issues.append("HIGH: Vulnerability handling procedure not formally documented")
        if not self.post_market_monitoring_recorded:
            issues.append("HIGH: Post-market monitoring results not recorded")
        if not self.security_testing_documented:
            issues.append("MEDIUM: Security testing not documented with results")
        if self.eu_authorized_representative is None:
            issues.append("CRITICAL: No EU authorized representative designated")
        if self.msa_contact_person is None:
            issues.append("MEDIUM: No internal MSA contact person designated")
        if not self.internal_escalation_procedure:
            issues.append("MEDIUM: No internal escalation procedure for MSA inquiries")
        return issues


# Example usage
product = MSAReadinessStatus(
    product_name="SecureEdgeGateway v2.1",
    product_class="Class I (default)",
    technical_docs_complete=True,
    technical_docs_last_updated=date(2026, 3, 15),
    sbom_current=True,
    sbom_format="CycloneDX 1.6",
    doc_of_conformity_signed=True,
    conformity_assessment_documented=True,
    vuln_handling_procedure_documented=True,
    post_market_monitoring_recorded=False,
    security_testing_documented=True,
    eu_authorized_representative="EU Tech Compliance GmbH, Munich",
    msa_contact_person=None,
    internal_escalation_procedure=False,
)

score, max_score = product.readiness_score()
print(f"MSA Readiness: {score}/{max_score} ({100*score//max_score}%)")
for gap in product.gaps():
    print(f"  - {gap}")

20-Item MSA Investigation Readiness Checklist

Documentation (7 items):

  1. Annex VII technical documentation package exists, is complete, and has a clear version and date
  2. SBOM is current, machine-readable (SPDX 2.3 or CycloneDX 1.6), and reflects the shipped version
  3. EU Declaration of Conformity is signed by an authorized person, dated, and specifies the conformity assessment procedure used
  4. Conformity assessment procedure is documented — which Annex VIII module, why it was selected, what it covered
  5. For third-party assessed products: NB certificate is valid, stored, and accessible
  6. Security testing evidence exists: test plans, test execution records, defect/remediation tracking
  7. Post-market monitoring process outputs are recorded, not just acted on

Process Documentation (4 items):

  1. Vulnerability handling procedure is formally documented (not just practiced)
  2. ENISA/CSIRT reporting procedure is documented including 24h/72h timeline triggers
  3. Patch release and verification procedure is documented
  4. Third-party component monitoring process (for SBOM components) is documented

Organizational Readiness (5 items):

  1. EU authorized representative is designated with actual operational authority
  2. Internal MSA contact person is designated — not just a legal entity, a named individual with authority
  3. Escalation procedure exists: who receives MSA inquiry → who approves response → who has documentation access
  4. Legal team briefed on CRA investigation procedure and confidentiality obligations
  5. Record retention schedule established for technical documentation (CRA requires 10 years post-market)

Response Preparedness (4 items):

  1. Documentation package can be assembled and delivered within 10 business days
  2. Team knows what "cooperation" means: what must be provided vs. what can be withheld
  3. Procedure exists for when an MSA requests source code access
  4. Manufacturer knows which national authority is the competent CRA MSA for their primary markets

Article 32 in the CRA Enforcement Timeline

The CRA's enforcement provisions enter into force on August 11, 2026 for products with digital elements in scope, with some components (cybersecurity requirements for products already in the market) on September 11, 2026.

MSA market surveillance begins on these dates. However, preparation at national authorities starts earlier. Member states designating MSAs must do so before enforcement, and many are using the run-up period to:

For manufacturers, the window between now and August 2026 is the time to get technical documentation into a state where it could be produced in response to an MSA audit. Once enforcement starts, the first wave of investigations will likely target documentation completeness — the easiest thing to verify and the most common gap.

Key Takeaways for Developers and Product Teams

MSAs have comprehensive powers. Documentation requests, physical inspections, testing, source code review in specific cases, mandatory corrective orders, recalls — the toolkit is complete. Non-cooperation is not an option.

SBOM confidentiality is legally protected. MSAs who receive SBOMs are bound by confidentiality. This should reduce resistance to producing SBOMs in response to MSA requests — withholding them creates more risk than sharing them under legally binding confidentiality.

ENISA coordinates, MSAs decide. ENISA is a technical resource and coordination hub, not a direct enforcement body. But ENISA involvement signals that an investigation has attracted EU-level attention.

Documentation quality matters more than documentation quantity. MSAs assess whether documentation reflects a genuine security development process. Documentation assembled to satisfy a form requirement — without underlying process evidence — is identifiable and creates more risk than no documentation.

Authorized representatives need real authority. For non-EU manufacturers, a nominal authorized representative who cannot actually access documentation or coordinate responses is not functional under CRA Article 32.

The first audits will focus on documentation. Given MSA resource constraints and the complexity of technical security assessment, initial enforcement will prioritize documentation completeness and the presence of required processes over deep technical product analysis. This means the documentation gap is the highest near-term risk.

See Also