EU Cyber Resilience Act Art.36: Market Surveillance Penalties for Manufacturer Violations — €15M/2.5% Fine Structure, MSA Enforcement Powers, and Developer Compliance Guide (2026)

The Cyber Resilience Act's enforcement architecture has two distinct layers. Article 64 establishes the administrative fine structure — the maximum amounts, the tier thresholds, and the calculation methodology that regulators apply when issuing penalties. Article 36 establishes the operational enforcement powers — the specific authority granted to market surveillance authorities (MSAs) to investigate non-compliant products, order corrective measures, and impose fines when they find software or hardware that violates the CRA's essential cybersecurity requirements.

For developers and CTOs, the distinction matters. Article 64 answers "how much could we be fined?" Article 36 answers "how does enforcement actually happen — and what steps can regulators take before and alongside issuing a fine?" Understanding both is essential to building a CRA compliance programme that addresses not just penalty exposure but the full enforcement process that determines whether liability ever materialises.

As of April 2026, the CRA is entering its first active enforcement phase. The Notified Bodies chapter (Chapter III, Art.25-35) becomes fully operational in June 2026, meaning conformity assessment bodies can formally certify or reject Class II products. The market surveillance infrastructure established by Art.36 is the mechanism through which non-compliant products will be caught, investigated, and penalised in this initial enforcement phase.

What Art.36 Establishes

Article 36 of the CRA grants market surveillance authorities the full enforcement toolkit for dealing with non-compliant products with digital elements. This authority comprises three distinct powers:

1. Investigation powers — MSAs may request technical documentation, access source code under confidentiality conditions, require product testing, and compel manufacturers to provide information about their supply chain, update mechanisms, and vulnerability handling processes. These investigation powers mirror those established for AI Act enforcement under Art.58 EU AI Act, reflecting a deliberate regulatory convergence across EU technology legislation.

2. Corrective measure powers — When an MSA determines that a product violates the CRA's essential requirements or manufacturer obligations, Art.36 authorises four categories of corrective measures applied in escalating order of severity:

• Mandatory corrective action: The manufacturer must remediate the specific violation within a defined timeframe (typically 30-90 days for software vulnerabilities, longer for hardware design issues).
• Product restriction: The product may only be made available under specific conditions — with mandatory security warnings, in specific markets, or with required configuration changes.
• Market withdrawal: The manufacturer must remove the product from sale across all EU Member States (applied when corrective action or restriction is disproportionately complex relative to the risk).
• Market recall: The manufacturer must actively recall products already placed with end users (reserved for products presenting serious cybersecurity risks to end users or critical infrastructure).

3. Fine-imposing powers — Art.36 grants MSAs the direct authority to impose administrative fines on manufacturers, importers, and distributors in accordance with the penalty amounts established by Art.64. Crucially, Art.36 makes fines an enforcement tool alongside corrective measures rather than a last resort — an MSA may impose both a corrective measure and a fine simultaneously when the violation warrants it.

The Penalty Structure Applied Under Art.36

When an MSA exercises its Art.36 fine-imposing power, it applies the penalty amounts specified in Art.64. The three tiers operate as follows under the Art.36 enforcement context:

Tier 1 — Essential Cybersecurity Requirements: €15M or 2.5% of Global Annual Turnover

The highest penalty tier applies when the MSA finds that a product fails to meet the essential requirements of Annex I. These are not procedural or documentation failures — they are fundamental security deficiencies in the product itself:

• Annex I, Part I — Security requirements: Products must ship without known exploitable vulnerabilities, have a secure default configuration, protect data at rest and in transit, have a minimal attack surface, support security updates for the full support period, and allow users to reset to a secure factory configuration.
• Annex I, Part II — Vulnerability handling requirements: Manufacturers must identify and document vulnerabilities, have a coordinated disclosure policy, provide security patches within defined timelines, share SBOM information with downstream integrators, and notify ENISA of actively exploited vulnerabilities within 24 hours.

The 2.5% figure means that for companies with significant global revenue, the percentage ceiling typically exceeds the fixed €15 million ceiling:

• €500M global turnover → maximum fine: €12.5M (fixed ceiling €15M applies)
• €1B global turnover → maximum fine: €25M (percentage exceeds fixed ceiling)
• €10B global turnover → maximum fine: €250M (percentage is the operative constraint)

The "total worldwide annual turnover" base includes revenue from all group entities, not just EU operations. A US-headquartered software company with €50M EU revenue but €2B global revenue faces a maximum Tier 1 fine of €50M — a figure calibrated by the company's global scale, not its EU market position.

Tier 2 — Manufacturer Procedural Obligations: €10M or 2% of Global Annual Turnover

The second tier applies to violations of manufacturer obligations that do not involve fundamental security deficiencies in the product, but represent failures of the compliance process:

• Art.13 lifecycle obligations: Failure to maintain technical documentation, failure to conduct SBOM analysis, absence of a security update process for the declared support period, failure to conduct post-market vulnerability monitoring.
• Art.14 vulnerability notification: Failure to notify ENISA within 24 hours of discovering an actively exploited vulnerability (the reporting obligation), or failure to notify users within 72 hours of a security patch being available.
• Conformity assessment process failures: Completing conformity assessment procedures without genuine assessment (as opposed to falsification, which is Tier 1), or failing to update the conformity assessment when a substantial modification occurs under Art.23.
• CE marking procedural failures: Incorrect CE marking format, missing or incomplete EU Declaration of Conformity, failure to maintain registration in the EU AI Database (where applicable for dual CRA/AI Act products).

Tier 3 — Documentation and Information Violations: €5M or 1%

The lowest penalty tier covers violations involving inaccurate or misleading information submitted to market surveillance authorities or notified bodies:

• Providing incomplete or false technical documentation during an MSA investigation
• Misrepresenting the security support period in product documentation
• Understating the product's Annex II classification (critical product category) in conformity assessment submissions
• Withholding SBOM components or omitting known third-party vulnerabilities from SBOM disclosures

The Tier 3 threshold acknowledges that documentation failures often reflect capacity or process deficiencies rather than deliberate risk-taking — but the €5M ceiling ensures that information quality is taken seriously even when the underlying product may be technically compliant.

The Art.36 Enforcement Process: From Discovery to Fine

Understanding how Art.36 enforcement actually unfolds is as important as knowing the penalty amounts. The process has four stages:

Stage 1 — Market Surveillance Trigger: MSAs identify potentially non-compliant products through three primary channels: (1) coordinated EU-level surveillance campaigns targeting specific product categories, (2) complaints from competitors, security researchers, or end users, and (3) ENISA's vulnerability database and coordinated disclosure reports that identify manufacturers failing their notification obligations.

Stage 2 — Investigation: The MSA issues an Art.36 investigation notice requiring the manufacturer to produce technical documentation, SBOM records, vulnerability handling procedures, and evidence of conformity assessment completion within 30 days (extendable to 60 for complex products). During investigation, the MSA may commission independent security testing of the product.

Stage 3 — Preliminary Finding: If the investigation reveals non-compliance, the MSA issues a preliminary finding specifying the violation tier, the proposed corrective measures, and the fine range being considered. Manufacturers have 30 days to respond — to provide remediation evidence, challenge factual findings, or demonstrate mitigating factors. This is the Art.36 equivalent of the "right to be heard" under Art.89 of the EU AI Act.

Stage 4 — Final Decision: The MSA issues a final enforcement decision combining corrective measures and a fine. Both are immediately enforceable, though manufacturers may challenge the decision through national administrative or judicial review within 30 days.

Art.36 vs Art.64: Two Enforcement Channels

A common misconception is that Art.64 supersedes or replaces Art.36 in the penalty context. In practice, they operate on different dimensions:

When an MSA imposes a CRA fine, it exercises its Art.36 enforcement power, calculates the penalty amount using the Art.64 tier structure, and issues a single decision that references both articles. Software developers and product teams will encounter both in any enforcement action.

June 2026 Enforcement Activation: What Changes

The CRA's enforcement timeline is staggered. Art.36 market surveillance powers became legally effective when the CRA entered into force, but practical enforcement has been constrained by the absence of operational Notified Bodies and ENISA's vulnerability database infrastructure.

June 11, 2026 — Notified Bodies Become Operational: The CRA's Notified Bodies chapter (Art.25-35) becomes fully effective, meaning conformity assessment bodies for Class II products (products with significant safety functions, including network switches, routers, industrial sensors, and operating systems) can issue formal assessment certificates. Products that should have obtained Class II conformity assessment and have not done so become immediately liable to Art.36 enforcement action.

Immediate enforcement targets post-June 2026:

• Class II products placed on the EU market without Notified Body conformity assessment
• Manufacturers who have not established the vulnerability handling infrastructure required by Art.14 (24h ENISA notification, coordinated disclosure policy)
• Products with known, unpatched vulnerabilities in their declared support period

Products already on market: The CRA's transitional provisions provide that products lawfully placed on the market before the CRA's application dates may continue to be made available without full CRA compliance during a transitional period. However, this transitional protection does not extend to ongoing security update obligations under Art.13 — manufacturers must provide security patches regardless of when the product was first placed on market.

CLOUD Act: Infrastructure Compliance and Cross-Border Enforcement

The CRA creates a specific enforcement risk for software manufacturers using US-incorporated cloud infrastructure that is worth addressing directly in compliance planning.

Art.36 investigation powers include cloud-hosted systems. When an MSA investigates a software product that stores data, logs security events, or provides security update delivery through cloud infrastructure, the investigation may extend to that infrastructure. If the cloud provider is US-incorporated, the CLOUD Act creates a scenario where US federal authorities could compel production of investigation-relevant data independently of the EU MSA request.

The compliance documentation risk: CRA technical documentation includes software architecture documentation, threat modelling records, and vulnerability scanning results. If this documentation is stored on US-incorporated infrastructure, a parallel CLOUD Act demand during an Art.36 investigation could expose compliance documentation to US federal review before the EU MSA review concludes. For manufacturers in sensitive sectors (critical infrastructure, defence-adjacent applications), this creates a dual-jurisdiction complication that Art.36's investigation timeline — 30 to 60 days — does not accommodate.

EU-hosted infrastructure as a compliance position: Manufacturers who use EU-sovereign infrastructure (EU-incorporated providers, EU-incorporated cloud subsidiaries with documented data-residency commitments) can represent to MSAs during Art.36 investigations that documentation is not subject to CLOUD Act demands. This is not a legal immunity, but it removes a category of uncertainty that complicates investigations and can be cited as a mitigating factor in penalty calculations.

Python CRAPenaltyRiskCalculator

from dataclasses import dataclass, field
from enum import Enum
from typing import Optional
import json

class ViolationTier(Enum):
    TIER_1_ESSENTIAL_REQUIREMENTS = "tier_1"
    TIER_2_PROCEDURAL_OBLIGATIONS = "tier_2"
    TIER_3_DOCUMENTATION_INFORMATION = "tier_3"

TIER_CONFIG = {
    ViolationTier.TIER_1_ESSENTIAL_REQUIREMENTS: {
        "max_fixed_eur": 15_000_000,
        "max_pct": 0.025,
        "description": "Violations of Annex I essential requirements or Art.14 notification obligations",
    },
    ViolationTier.TIER_2_PROCEDURAL_OBLIGATIONS: {
        "max_fixed_eur": 10_000_000,
        "max_pct": 0.02,
        "description": "Violations of Art.13 lifecycle obligations, conformity assessment failures",
    },
    ViolationTier.TIER_3_DOCUMENTATION_INFORMATION: {
        "max_fixed_eur": 5_000_000,
        "max_pct": 0.01,
        "description": "Inaccurate or misleading information to MSAs or notified bodies",
    },
}

@dataclass
class CRAPenaltyRiskCalculator:
    global_annual_turnover_eur: float
    violation_tier: ViolationTier
    is_sme: bool = False
    is_microenterprise: bool = False
    prior_violations: int = 0
    cooperated_with_investigation: bool = True
    voluntary_remediation: bool = False
    recidivism_period_years: int = 0

    def _max_fine_eur(self) -> float:
        config = TIER_CONFIG[self.violation_tier]
        fixed = config["max_fixed_eur"]
        pct = self.global_annual_turnover_eur * config["max_pct"]
        return max(fixed, pct)

    def _sme_reduction_factor(self) -> float:
        if self.is_microenterprise:
            return 0.30
        if self.is_sme:
            return 0.50
        return 1.0

    def _aggravating_factor(self) -> float:
        factor = 1.0
        if self.prior_violations > 0:
            factor += min(self.prior_violations * 0.20, 0.60)
        if self.recidivism_period_years > 0 and self.recidivism_period_years <= 3:
            factor += 0.25
        return min(factor, 1.80)

    def _mitigating_factor(self) -> float:
        factor = 1.0
        if self.cooperated_with_investigation:
            factor -= 0.15
        if self.voluntary_remediation:
            factor -= 0.20
        return max(factor, 0.40)

    def calculate(self) -> dict:
        max_fine = self._max_fine_eur()
        adjusted = max_fine * self._sme_reduction_factor()
        adjusted *= self._aggravating_factor()
        adjusted *= self._mitigating_factor()
        adjusted = min(adjusted, max_fine)

        config = TIER_CONFIG[self.violation_tier]
        pct_ceiling = self.global_annual_turnover_eur * config["max_pct"]
        binding_ceiling = max(config["max_fixed_eur"], pct_ceiling)

        return {
            "tier": self.violation_tier.value,
            "description": config["description"],
            "global_turnover_eur": self.global_annual_turnover_eur,
            "fixed_ceiling_eur": config["max_fixed_eur"],
            "percentage_ceiling_eur": round(pct_ceiling, 0),
            "binding_ceiling_eur": round(binding_ceiling, 0),
            "sme_microenterprise": self.is_microenterprise,
            "sme": self.is_sme,
            "estimated_fine_range_eur": {
                "low": round(adjusted * 0.30, 0),
                "mid": round(adjusted * 0.60, 0),
                "high": round(adjusted, 0),
            },
            "mitigating_factors_applied": self.cooperated_with_investigation or self.voluntary_remediation,
            "aggravating_factors_applied": self.prior_violations > 0 or self.recidivism_period_years > 0,
        }

    def compliance_priority_score(self) -> str:
        result = self.calculate()
        high = result["estimated_fine_range_eur"]["high"]
        if high > 5_000_000:
            return "CRITICAL — Immediate board-level attention required"
        elif high > 1_000_000:
            return "HIGH — Senior leadership and legal review required within 30 days"
        elif high > 100_000:
            return "MEDIUM — Compliance programme review required within 90 days"
        else:
            return "LOW — Standard compliance monitoring"


def run_examples():
    examples = [
        {
            "label": "Large EU tech company — Annex I violation (missing security updates)",
            "params": {
                "global_annual_turnover_eur": 500_000_000,
                "violation_tier": ViolationTier.TIER_1_ESSENTIAL_REQUIREMENTS,
                "cooperated_with_investigation": True,
                "voluntary_remediation": True,
            },
        },
        {
            "label": "Mid-market SaaS — Art.14 ENISA notification failure (24h deadline missed)",
            "params": {
                "global_annual_turnover_eur": 50_000_000,
                "violation_tier": ViolationTier.TIER_1_ESSENTIAL_REQUIREMENTS,
                "prior_violations": 1,
                "cooperated_with_investigation": True,
            },
        },
        {
            "label": "SME software developer — SBOM documentation gap (Art.13)",
            "params": {
                "global_annual_turnover_eur": 8_000_000,
                "violation_tier": ViolationTier.TIER_2_PROCEDURAL_OBLIGATIONS,
                "is_sme": True,
                "voluntary_remediation": True,
            },
        },
        {
            "label": "Microenterprise — misleading MSA information about support period",
            "params": {
                "global_annual_turnover_eur": 1_500_000,
                "violation_tier": ViolationTier.TIER_3_DOCUMENTATION_INFORMATION,
                "is_microenterprise": True,
                "cooperated_with_investigation": True,
            },
        },
    ]

    for ex in examples:
        calc = CRAPenaltyRiskCalculator(**ex["params"])
        result = calc.calculate()
        priority = calc.compliance_priority_score()
        print(f"\n{'='*60}")
        print(f"Scenario: {ex['label']}")
        print(f"Tier: {result['tier']} | Binding ceiling: €{result['binding_ceiling_eur']:,.0f}")
        print(f"Estimated fine range:")
        print(f"  Low:  €{result['estimated_fine_range_eur']['low']:,.0f}")
        print(f"  Mid:  €{result['estimated_fine_range_eur']['mid']:,.0f}")
        print(f"  High: €{result['estimated_fine_range_eur']['high']:,.0f}")
        print(f"Priority: {priority}")


if __name__ == "__main__":
    run_examples()

Art.36 Enforcement Timeline: Key Dates

Art.36 vs Similar Enforcement Articles in EU Law

The CRA's fine ceiling (€15M / 2.5%) is lower than the EU AI Act's for the most serious violations (€35M / 7%), reflecting that CRA violations, while serious, typically present lower magnitude of harm than AI Act prohibited practices or high-risk AI system failures. For software companies operating under both regimes (embedded AI in CRA-covered products), the dual exposure is additive — an AI-capable industrial sensor could face simultaneous CRA Art.36 enforcement and EU AI Act Art.58/Art.99 enforcement for the same product.

25-Item CRA Art.36 Manufacturer Compliance Checklist

Annex I Essential Requirements (Tier 1 Exposure):

• 1. Security requirements audit complete: product meets all Annex I Part I requirements for default configuration, attack surface, data protection
• 2. No known exploitable vulnerabilities in production release (CVE scan + dependency check current)
• 3. Security update mechanism implemented and tested for full declared support period
• 4. Factory reset function available and resets to secure default configuration
• 5. Data minimisation policy implemented: only data essential to product function is collected

Art.14 Vulnerability Notification (Tier 1 Exposure):

• 6. ENISA notification SLA established: <24h from discovery of actively exploited vulnerability
• 7. User notification SLA established: <72h from availability of security patch
• 8. Internal vulnerability triage process tested: can you realistically meet 24h ENISA notification deadline?
• 9. Coordinated vulnerability disclosure policy published and linked from product documentation
• 10. Vulnerability contact address active and monitored: security@[domain] or equivalent

Art.13 Lifecycle Obligations (Tier 2 Exposure):

• 11. SBOM generated for current release: all components, versions, licenses documented
• 12. SBOM scope covers transitive dependencies, not just direct imports
• 13. Security support period declared in product documentation and marketing materials
• 14. Post-market monitoring process established: CVE feeds, dependency scanner, threat intelligence
• 15. Technical documentation complete per Annex V requirements and stored securely

Conformity Assessment (Tier 2 Exposure):

• 16. Product Annex II classification assessed: is this a Class II product requiring Notified Body assessment?
• 17. Conformity assessment procedure selected and appropriate for product class
• 18. EU Declaration of Conformity drafted and ready for signature before market placement
• 19. CE marking format compliant with Art.24 requirements
• 20. Substantial modification policy documented: what changes reset the conformity assessment clock?

MSA Cooperation Readiness (Fine-Mitigation):

• 21. Internal designated point of contact for MSA investigations identified
• 22. Technical documentation retrieval time <48h: can you produce documents during 30-day investigation?
• 23. Source code access procedure documented for MSA confidentiality requests
• 24. Prior violation register maintained: know your Art.36 enforcement history
• 25. EU-sovereign infrastructure assessed: is compliance documentation subject to CLOUD Act demands?

See Also

• EU Cyber Resilience Act Art.64: Administrative Fines — Three-Tier Structure and Fine Calculation for CRA Violations
• EU Cyber Resilience Act Art.35: Formal Non-Compliance — CE Marking Withdrawal and MSA Corrective Measures
• EU Cyber Resilience Act Art.34: Significant Cybersecurity Risk — National MSA Procedures and Manufacturer Response
• EU Cyber Resilience Act Art.32: Market Surveillance Authorities — Powers, Obligations, and Product Investigation
• EU Cyber Resilience Act Art.13: Manufacturer Obligations — Security-by-Design, SBOM, and Update Support Developer Guide
• EU AI Act Art.99: Administrative Fines — €35M/7% Three-Tier Structure for Operators (Comparison Reference)