CRA Art.21: Cooperation with Market Surveillance Authorities — Traceability, Recall & Significant Risk Notification (Developer Guide 2026)

Post #467 in the sota.io EU Cyber Compliance Series

The EU Cyber Resilience Act (Regulation (EU) 2024/2847, "CRA") distributes compliance obligations across the entire product supply chain. Manufacturers carry the heaviest burden under Art.13, while importers (Art.18), distributors (Art.19), and authorised representatives (Art.12) each bear their own role-specific duties. Article 21 adds a horizontal layer that sits on top of all these provisions: the obligation to cooperate with market surveillance authorities (MSAs) on demand.

Art.21 is not a passive obligation. It does not merely require operators to avoid obstructing inspections. It creates affirmative duties to provide documentation, identify supply chain participants, allow physical access, provide product samples, and — critically — take corrective action when an MSA determines a product presents a cybersecurity risk. Non-cooperation with an MSA under Art.21 is an independent compliance failure, separate from any substantive product non-conformity.

Critical deadline: 11 December 2027. Art.21 cooperation obligations apply in full from that date. However, operators should establish their MSA cooperation infrastructure well in advance — market surveillance frameworks take time to build, and an MSA request arriving without a response protocol in place will expose the operator to enforcement action under Art.64 (penalties up to €15 million or 2.5% of global annual turnover).

Who Is Subject to Art.21?

Art.21 applies to all economic operators under the CRA:

• Manufacturers (Art.13): the primary target of CRA obligations
• Authorised representatives (Art.12): who act on behalf of non-EU manufacturers
• Importers (Art.18): who place non-EU manufacturers' products on the EU market
• Distributors (Art.19): who make products available on the EU market

The obligation is symmetric — each operator must cooperate with MSAs regarding their own activities and records. A distributor cannot deflect an MSA investigation by pointing to the manufacturer; the distributor must cooperate regarding the distributor's own records, actions, and supply chain knowledge.

Open-source software stewards (Art.8) have a lighter cooperation obligation proportionate to their limited formal role in placing products on the market, but are not entirely exempt where they exercise effective control over a product's security posture.

The Three Art.21 Obligations

Art.21(1) — General Cooperation Duty

Upon MSA request, economic operators shall cooperate in any action taken to eliminate or, if that is not possible, mitigate cybersecurity risks presented by products they have made available on the market.

"Cooperation" is deliberately open-ended. In the context of CRA market surveillance (operating under Regulation (EU) 2019/1020, the Union product market surveillance framework), cooperation encompasses:

Documentation and Records

Operators must provide MSAs with access to all documentation relevant to:

• Conformity assessments and technical documentation
• SBOM records and vulnerability tracking logs
• Communication records with manufacturers, importers, or distributors upstream and downstream
• Security update history and patch release notes
• Incident reports filed under Art.14/15

Physical Access and Samples

Regulation (EU) 2019/1020 grants MSAs authority to require physical access to premises, products, and manufacturing facilities. Economic operators must:

• Permit MSA inspectors entry to warehouses, offices, and production facilities
• Provide product samples for testing and analysis
• Not obstruct or delay inspections

For software-only products, "physical access" translates to access to build environments, repository access logs, deployment configurations, and testing documentation.

Corrective Action Implementation

When an MSA has taken action under Art.55 (national procedure for products presenting a cybersecurity risk) and has determined that a product must be recalled, withdrawn from the market, or restricted, economic operators who have made that product available must implement the corrective action within the specified timeframe.

Art.21(2) — Supply Chain Traceability

Art.21(2) creates the traceability backbone of Art.21. Upon MSA request, every economic operator must be able to identify:

• Any economic operator who supplied the product to them
• Any economic operator to whom they have supplied the product

This creates the audit trail an MSA needs to trace a cybersecurity risk from an end-user complaint back to its root cause in the supply chain. The identification obligation applies for the full retention period.

Practical implication: Operators must maintain structured supplier and customer registries, not merely invoices. An MSA request for supply chain identification must be answerable with name, address, and contact information for each relevant operator — not an accounting system search that takes three weeks. The registry must be product-specific and date-queryable.

Art.21(3) — Significant Cybersecurity Risk Proactive Notification

Art.21(3) goes beyond reactive cooperation. When an economic operator has reason to believe that a product they have made available on the market presents a significant cybersecurity risk, they must:

1. Immediately inform the MSA of the Member State where they are established
2. Notify the manufacturer if the operator is not the manufacturer
3. Inform end users who have received the product, providing sufficient information for protective measures

This obligation sits independently of the Art.14/15 manufacturer vulnerability reporting framework. Art.21(3) binds distributors and importers who are not manufacturers — operators who discover or are informed of a significant cybersecurity risk in a product they distribute must act, even if the manufacturer has not yet responded.

What Counts as "Significant Cybersecurity Risk"?

The CRA does not provide a bright-line definition of "significant" in Art.21(3). However, from the Art.14 reporting framework (which covers "actively exploited vulnerabilities" and "severe incidents with significant impact"), the following indicators point to significant risk:

The "reason to believe" threshold is an objective standard — it does not require certainty. An importer who receives a credible vulnerability disclosure from a researcher, or who sees a CVE entry affecting their distributed product with a CVSS ≥9.0, has "reason to believe" and must act under Art.21(3).

Timing: The word "immediately" in Art.21(3) does not have an explicit hour window in the CRA text itself, but read in context with Art.14(3)'s 24-hour early warning for manufacturers, immediate notification means within 24–48 hours of the operator becoming aware of the significant risk.

The Recall Lifecycle Under Art.55 and Art.21

When an MSA initiates corrective action under Art.55, the recall lifecycle follows a defined sequence in which Art.21 obligations are triggered at Phase 3.

Phase 1: MSA Risk Assessment (Art.55(1)–(2))

The MSA identifies a product presenting a cybersecurity risk — through its own testing, a third-party report, an Art.21(3) notification, or an Art.14/15 vulnerability report. The MSA assesses whether the risk requires corrective action beyond what the manufacturer has already taken.

Phase 2: Operator Consultation

Before issuing a corrective action order, the MSA consults the economic operator concerned. This is the operator's opportunity to present evidence that:

• The risk has already been mitigated by a security update
• The risk does not meet the threshold for mandatory corrective action
• The corrective action proposed is disproportionate

Phase 3: Corrective Action Order (Art.55(3))

If the MSA determines corrective action is required, it issues an order specifying:

• The nature of the action: patch release, market withdrawal, or product recall
• The timeframe for compliance
• Reporting requirements for implementation confirmation

Upon receiving an Art.55(3) order, Art.21 obligations activate:

1. Acknowledge receipt and stated intent to comply
2. Notify downstream recipients: customers, resellers, end users who received the product
3. Implement the required action within the specified timeframe
4. Report completion to the MSA with supporting evidence (deployment logs, customer notification records, return/destruction documentation)

Phase 4: Cross-Border Escalation (Art.56)

If the home Member State MSA determines a Union-wide response is required, it notifies the Commission through Safety Gate (the EU product risk notification system). The Commission may issue a Union safeguard decision under Art.56 — triggering parallel corrective action obligations across all Member States where the product is available. At this point, every national MSA in every affected Member State can independently enforce against operators under their jurisdiction.

The 10-Year Record Retention Architecture

Art.21 cooperation obligations presuppose that operators maintain adequate records. The retention requirements align across CRA provisions:

For software products with continuous updates, the "placing on market" date requires careful definition. Per ENISA guidance on CRA implementation, the 10-year clock runs from the end-of-support date for each major version — meaning a product still receiving security updates has a rolling retention obligation.

Database design implication: Supply chain records cannot be in a single table with a fixed deletion schedule. They must be keyed to product version and EOL date, with cascading retention enforcement.

National MSA Contact Points

Each EU Member State designates MSAs for CRA product surveillance. For ICT and software products, the primary contacts are:

Operators making products available in multiple Member States must maintain a contact registry for each relevant national MSA. An MSA in the operator's home Member State has primary jurisdiction, but any MSA in a Member State where the product is available can initiate Art.55 proceedings.

Python Implementation: CRAMSACooperationKit

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


class OperatorRole(Enum):
    MANUFACTURER = "manufacturer"
    AUTHORISED_REP = "authorised_representative"
    IMPORTER = "importer"
    DISTRIBUTOR = "distributor"


class RiskLevel(Enum):
    NONE = "none"
    LOW = "low"
    MODERATE = "moderate"
    SIGNIFICANT = "significant"
    CRITICAL = "critical"


@dataclass
class SupplyChainRecord:
    operator_name: str
    operator_address: str
    operator_contact_email: str
    role: OperatorRole
    product_identifier: str
    product_version: str
    transaction_date: date
    units_transferred: Optional[int] = None
    product_eol_date: Optional[date] = None
    retention_until: date = field(init=False)

    def __post_init__(self):
        # 10 years from EOL date if known, else from transaction date
        base = self.product_eol_date or self.transaction_date
        self.retention_until = date(base.year + 10, base.month, base.day)

    def is_within_retention(self) -> bool:
        return date.today() <= self.retention_until


@dataclass
class MSACooperationResponse:
    request_reference: str
    msa_name: str
    msa_member_state: str
    request_date: date
    requested_records: list[str]
    deadline_days: int

    acknowledged_at: Optional[datetime] = None
    records_provided_at: Optional[datetime] = None
    corrective_action_completed_at: Optional[datetime] = None

    @property
    def response_deadline(self) -> date:
        return self.request_date + timedelta(days=self.deadline_days)

    @property
    def is_overdue(self) -> bool:
        return date.today() > self.response_deadline and self.records_provided_at is None


@dataclass
class CybersecurityRiskNotification:
    """Art.21(3) significant risk notification record."""
    product_id: str
    product_version: str
    risk_description: str
    risk_level: RiskLevel
    cve_ids: list[str]
    cvss_score: Optional[float]

    msa_notified_at: Optional[datetime] = None
    manufacturer_notified_at: Optional[datetime] = None
    end_users_notified_at: Optional[datetime] = None

    @property
    def triggers_art21_3(self) -> bool:
        return (
            self.risk_level in (RiskLevel.SIGNIFICANT, RiskLevel.CRITICAL)
            or (self.cvss_score is not None and self.cvss_score >= 9.0)
        )

    def all_notifications_sent(self) -> bool:
        return all([
            self.msa_notified_at,
            self.manufacturer_notified_at,
            self.end_users_notified_at,
        ])


class CRAMSACooperationKit:
    """
    Manages Art.21 cooperation obligations: supply chain records,
    MSA request responses, and significant risk notifications.
    """

    def __init__(self, operator_name: str, operator_role: OperatorRole):
        self.operator_name = operator_name
        self.operator_role = operator_role
        self.supply_chain_records: list[SupplyChainRecord] = []
        self.msa_responses: list[MSACooperationResponse] = []
        self.risk_notifications: list[CybersecurityRiskNotification] = []

    def add_supply_chain_record(self, record: SupplyChainRecord) -> None:
        self.supply_chain_records.append(record)

    def identify_supply_chain(
        self, product_identifier: str
    ) -> dict[str, list[SupplyChainRecord]]:
        """Art.21(2): identify upstream and downstream operators for a product."""
        active = [
            r for r in self.supply_chain_records
            if r.product_identifier == product_identifier
            and r.is_within_retention()
        ]
        return {
            "upstream": [
                r for r in active
                if r.role in (OperatorRole.MANUFACTURER, OperatorRole.IMPORTER)
            ],
            "downstream": [
                r for r in active
                if r.role == OperatorRole.DISTRIBUTOR
            ],
        }

    def register_msa_request(
        self, request: MSACooperationResponse
    ) -> MSACooperationResponse:
        self.msa_responses.append(request)
        return request

    def get_overdue_responses(self) -> list[MSACooperationResponse]:
        return [r for r in self.msa_responses if r.is_overdue]

    def assess_significant_risk(
        self, notification: CybersecurityRiskNotification
    ) -> dict[str, bool]:
        """
        Art.21(3): assess risk and return required notification targets.
        Operator must notify MSA + manufacturer (if not self) + end users.
        """
        if not notification.triggers_art21_3:
            return {"msa": False, "manufacturer": False, "end_users": False}

        self.risk_notifications.append(notification)
        return {
            "msa": True,
            "manufacturer": self.operator_role != OperatorRole.MANUFACTURER,
            "end_users": True,
        }

    def compliance_report(self) -> dict:
        return {
            "operator": self.operator_name,
            "role": self.operator_role.value,
            "supply_chain_records_active": sum(
                1 for r in self.supply_chain_records if r.is_within_retention()
            ),
            "supply_chain_records_expired": sum(
                1 for r in self.supply_chain_records if not r.is_within_retention()
            ),
            "msa_requests_total": len(self.msa_responses),
            "msa_requests_overdue": len(self.get_overdue_responses()),
            "risk_notifications_total": len(self.risk_notifications),
            "risk_notifications_complete": sum(
                1 for n in self.risk_notifications if n.all_notifications_sent()
            ),
            "report_date": date.today().isoformat(),
        }

Art.21 Compliance Checklist

Supply Chain Traceability (Art.21(2))

• Structured supplier registry: name, address, contact email per product and version
• Structured customer/reseller registry per product and version
• Records retained for 10 years from EOL date (not just transaction date)
• Registry queryable by product identifier, version, and date range
• MSA-ready export format available within 48 hours of request

MSA Cooperation Readiness (Art.21(1))

• Designated Art.21 contact person: name and direct email
• MSA contact registry for each Member State where products are available
• Response protocol: MSA request → acknowledgement within 24 hours
• Documentation package prepared: EU DoC, technical documentation, SBOM
• Physical/logical access protocol for MSA inspection requests

Significant Risk Notification (Art.21(3))

• Risk assessment process for incoming vulnerability reports
• CVSS scoring procedure defined for CVEs affecting distributed products
• MSA notification template (national language + English)
• End-user notification template (plain language, actionable steps)
• Escalation path to manufacturer defined (if operator is not manufacturer)
• Notification tracking log with timestamps

Corrective Action Capability

• Recall and withdrawal procedure documented
• Customer notification infrastructure (email, in-app alert)
• Software rollback and update deployment capability
• Destruction and disposal documentation procedure
• MSA completion report template ready

Cross-Article Integration

• Art.14/15 vulnerability reporting (manufacturer) feeds Art.21(3) risk assessment
• Art.13(16) 10-year documentation retention aligned with Art.21(2) records
• Art.18 importer risk assessment (Art.18(7)) triggers Art.21(3) review
• Art.19 distributor corrective action (Art.19(5)) aligned with Art.21(1)
• Art.55/56 corrective action order → Art.21 customer notification workflow

Art.21 and sota.io: EU-Native Infrastructure Advantages

For operators building products with digital elements on EU infrastructure, Art.21 cooperation with national MSAs is structurally simpler when all components are EU-resident:

• Single-jurisdiction data access: MSAs in your Member State can access logs, supply chain records, and product data without cross-jurisdictional transfer complications.
• No CLOUD Act conflict: US-parent infrastructure creates a structural conflict between EU MSA requests (requiring disclosure) and US government orders (potentially restricting disclosure). EU-native infrastructure eliminates this conflict entirely.
• ENISA coordination alignment: ENISA's CRA coordination role (Art.59) operates within an EU-only data framework. PaaS providers without US parents are not subject to requests that could compromise the integrity of MSA cooperation records.

This guide covers obligations under Regulation (EU) 2024/2847 (CRA) Article 21. Cross-references: Art.12 (authorised representatives), Art.13 (manufacturer obligations), Art.18 (importer obligations), Art.19 (distributor obligations), Art.20 (substantial modification), Art.55 (national procedures for products presenting cybersecurity risk), Art.56 (Union safeguard procedure), Art.59 (ENISA's role), Art.64 (penalties), Regulation (EU) 2019/1020 (market surveillance framework).

See Also

• CRA Art.32: Market Surveillance Authorities — Powers and Investigation — the MSA powers that back up Art.21 cooperation obligations
• CRA Art.13: Manufacturer Obligations — core duties MSAs audit when investigating products under Art.21
• CRA Art.16: Vulnerability Reporting to ENISA — ENISA coordination role referenced in Art.21 market surveillance context