The device is done. Firmware is stable, the enclosures are back from the factory, the first batch is on a pallet waiting to ship into the EU. One thing left: CE marking.
You look it up, and you draw the obvious conclusion. One stamp, one process, one box to tick.
It isn't. CE marking is the visible outcome of several separate compliance processes running in parallel. Each has its own rules, its own documentation, its own declaration. For most connected hardware today that means two regulations at once: the Cyber Resilience Act (CRA) and, if your device has a radio module, the Radio Equipment Directive (RED). This guide is about how they fit together, and what you actually need to do, in what order.
We'll walk the realistic path most manufacturers take: self-assessment. You evaluate your own product's compliance, and you don't pay a notified body to do it for you. For the majority of connected devices that route is open. Where it's closed, we'll say so plainly.
Step 0: Does This Even Apply to You?
Work out first which rules are actually in scope for your product.
- Does your product have "digital elements": software, firmware, or the ability to connect to a network or another device? If yes, the CRA applies.
- Does your product have a radio module: Wi-Fi, Bluetooth, cellular, LoRa, anything using the radio spectrum? If yes, the RED applies too, specifically its cybersecurity provisions.
Most IoT and connected hardware will land under both. That's not a mistake in the law. It's a temporary overlap, and it's about to be resolved (more on that below).
Step 1: The Big Picture, or Why Two Laws at Once
Here's where almost everyone gets confused, including manufacturers established in the EU for decades who have seen their share of CE marks. RED and CRA aren't competing regulations. They're the same regulatory intent, arriving in two waves.
- The RED's cybersecurity requirements (Delegated Regulation 2022/30: network protection, data privacy, fraud prevention) have applied since 1 August 2025. If your device has a radio module and it connects to the internet, processes personal data, or handles financial transactions, these rules are live right now.
- The CRA is broader. It covers cybersecurity for any product with digital elements, radio or not. It entered into force in December 2024, but the obligations phase in over several years. Vulnerability reporting duties start 11 September 2026. The full regime, meaning secure-by-design requirements, conformity assessment and CE marking, becomes mandatory on 11 December 2027.
- Once the CRA is fully in force, the RED's separate cybersecurity delegated act is repealed. One detail matters here: that repeal has already been formally adopted, through Delegated Regulation (EU) 2026/339 in February 2026. It just doesn't take effect until 11 December 2027, the same day the CRA becomes fully applicable. In substance the CRA absorbs the RED's cybersecurity regime, because its essential requirements already cover everything Article 3(3)(d), (e) and (f) of the RED require.
In practical terms: right now, in 2026, a radio-connected product needs to satisfy RED's cybersecurity rules. From December 2027 onward, the CRA becomes the single framework covering the same ground. You aren't choosing between them. You're living through a handover period, and for now both apply.
If you're still mapping out the full regulation, our complete guide to the EU Cyber Resilience Act covers requirements and deadlines end to end. And if you want the conceptual picture first, what the mark actually certifies and what it doesn't, our companion piece on what CE marking means under the CRA is the shorter read.
Step 2: Classify Your Product
Not every product faces the same level of scrutiny. The CRA sorts products into four risk tiers, and the tier determines whether self-assessment is even available to you:
- Default category (most IoT devices, smart home products, general connected hardware): self-assessment is allowed, no restrictions.
- Important Class I (routers, password managers, smart home hubs, browsers, and similar): self-assessment is allowed if you fully apply a recognized harmonized standard; otherwise a notified body gets involved.
- Important Class II (hypervisors, firewalls, intrusion detection/prevention systems, and tamper-resistant microprocessors/microcontrollers, a short and fixed list): third-party assessment is mandatory, and self-assessment isn't an option.
- Critical (smart cards, secure elements, smart meter gateways): the highest level of scrutiny, potentially requiring formal cybersecurity certification.
Most connected consumer and industrial hardware, the kind Platanor's clients typically build, falls into the default or Important Class I tiers, where self-assessment is realistic. Work out exactly where your product sits early, because it decides the entire rest of your path.
For the detailed breakdown of each tier, including specific product examples and how to document your reasoning, see our guide to CRA product classification. If you'd rather work through it interactively, our free CRA Readiness Check classifies your product as part of the scope screen.
Step 3: Build the Technical Documentation
This is the substantive work. It's also the part with the most overlap with what your engineering team is already doing, or should be. Regulators expect a file that includes:
- A general product description and its intended use
- The security architecture and design concept
- A documented risk assessment and its results
- A complete Software Bill of Materials (SBOM): a structured, machine-readable list of the software components in your product, covering at minimum the top-level dependencies
- A description of your vulnerability management process
- Test results and examination reports
- A description of your update mechanism
On the SBOM specifically. The law itself only requires a "commonly used and machine-readable format" and doesn't name one. In practice the market has converged on two: CycloneDX and SPDX. Neither is legally mandatory, but both are purpose-built for this, widely tooled, and make it far easier to automatically cross-reference your dependencies against vulnerability databases like the CISA KEV or OSV.dev. With a prose PDF or an unstructured spreadsheet, that's much harder to do reliably. If you don't have tooling in place yet, build it now, while no deadline is standing over you.
For the full walkthrough, including what a complete SBOM entry needs to contain and how to generate one for embedded firmware specifically, see our SBOM guide for IoT manufacturers.
This documentation isn't a one-time deliverable, either. It needs to be kept up to date, and retained for at least 10 years, or your product's support period if that's longer (see below).
Step 4: Run the Conformity Assessment (Self-Assessment / "Module A")
This is where the actual evaluation happens. Under the CRA's internal control procedure, commonly called Module A, you check your own product against the essential cybersecurity requirements. On your own responsibility. Without an external body reviewing your work.
Nobody checks your homework before you hand it in. They check it later, under circumstances you don't get to pick, which is exactly why the documentation from Step 3 matters as much as it does. If something goes wrong, that file is your evidence that the work was done.
If a relevant harmonized standard exists and you apply it fully, your product benefits from a "presumption of conformity" for the parts of the product that standard covers. Two things to keep in mind. First, the presumption is often partial: a standard covering, say, network protection doesn't automatically cover privacy or fraud-prevention requirements too. Second, applying a standard never removes your obligation to carry out your own risk assessment. Responsibility for your product's security stays with you, standard or no standard.
Step 5: Address RED Separately (If You Have Radio)
If your product has a radio module, don't assume Step 4 covers you. RED's cybersecurity requirements (Article 3.3 d/e/f) need their own assessment, currently running in parallel with CRA.
Since January 2025, self-declaration is available here too, through harmonized standards (the EN 18031 series). But there's a catch worth knowing before you count on it: these standards were published with restrictions. Self-declaration only works cleanly for products that fall within those restrictions. Outside them, a notified body still needs to be involved. Check this carefully rather than assuming the simple path is automatically open to you.
One more thing, if you're building on a third-party radio module or System-on-Module (SOM). The module itself is typically not subject to these cybersecurity requirements when shipped as a bare component requiring integration, and module vendors will often mark it "N/A" in their own declaration of conformity. That takes nobody off the hook. It moves responsibility to whoever integrates the module into a finished product. Buying a "certified" radio module does not certify your final device.
Step 6: Write the EU Declaration of Conformity
Once your assessment is complete, you draw up a signed EU Declaration of Conformity (DoC): a formal written statement, under your own responsibility, that your product meets the requirements. It identifies the product, references the regulations it complies with, states which assessment module you used, and carries a signature with a name, role, date, and place.
There's also a simplified version for situations where space is limited (product packaging, a user manual), consisting of a short statement plus a stable URL pointing to the full declaration online.
Step 7: Affix the CE Mark
The mark goes on after the declaration is signed. Not before. It's the visible signal to the market, and to enforcement authorities, that everything behind it has been done.
Step 8: Your Job Isn't Over - Post-Market Obligations
This is the step manufacturers most often underestimate. CE marking isn't a finish line. It's the start of an ongoing set of duties.
Vulnerability and incident reporting. From 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents through a central reporting platform, on a fixed clock: a 24-hour early warning and a 72-hour detailed report. The final report has two different deadlines depending on the trigger. For an actively exploited vulnerability, it's due within 14 days of a corrective update becoming available. For a severe incident, it's due within one month of the notification being submitted. This applies to every in-scope product already on the market too, not just new ones. Our Article 14 preparation guide covers what an operational reporting process needs to look like before that date.
The support period. You must commit to a period during which you'll handle vulnerabilities and provide security updates. Five years is commonly treated as a default benchmark, but it isn't automatic or one-size-fits-all in either direction. If your product is reasonably expected to stay in use longer, which is normal for industrial or embedded hardware, your support period should reflect that. For genuinely short-lived products it can legitimately be shorter: the regulation itself gives the example of an app built to support a time-limited public health campaign. Either way, document your reasoning for whatever length you choose, and state the end date clearly to buyers at the point of purchase.
What Should You Actually Do Right Now, in 2026?
Given the staggered deadlines, here's a realistic order of operations if you're starting today:
- Now: Start building your SBOM process and vulnerability-handling policy. Don't wait for a deadline to force it. This takes longer to build properly than most teams expect.
- Before 11 September 2026: Have a working incident and vulnerability reporting process in place. This deadline doesn't care whether your product is brand new or five years old.
- Through 2026–2027: Watch for harmonized standards being published (most are expected through late 2026 and into 2027) and fold them into your development process as they become available.
- By 11 December 2027: Full conformity for anything newly placed on the market. Technical documentation, conformity assessment, EU Declaration of Conformity, CE marking.
There's no general grace period built into any of these dates. Your runway is the stretch of time before each deadline, not after it.
Common Questions That Come Up
"I don't manufacture the hardware myself - I white-label an OEM product. Does this still apply to me?" Yes. What matters under the CRA isn't who physically built the device. It's whose name or brand is on it. If you sell it under your own brand, you're the manufacturer, with the full set of obligations, even if someone else designed and built it.
"I already have this product on the market. Do I need to redo everything?" Mostly no, for full conformity. Products already placed on the market before 11 December 2027 are largely grandfathered, as long as nothing "substantial" changes about them afterward. Routine bug fixes and security patches don't count as substantial changes. But there's one exception: vulnerability and incident reporting duties apply to all in-scope products from September 2026, including ones already sold.
"How much could this actually cost me if I get it wrong?" Penalties are tiered by severity. The most serious violations, non-compliance with essential security requirements, can reach up to €15 million or 2.5% of global annual turnover, whichever is higher. Less severe violations top out at €10 million (2%) or €5 million (1%) depending on the nature of the breach. Authorities can also order products withdrawn from the market on top of any fine. There's a narrow exception for very small businesses, but it only covers missed reporting deadlines, not general non-compliance.
Where This Fits With What We Do
None of this documentation, not the SBOM, not the risk assessment, not the technical file, has to be a separate compliance exercise bolted on at the end. Done properly it's a natural output of solid firmware engineering: understanding what's in your product, how it's built, and how you'll keep it secure over time. That's the work Platanor does day to day. Compliance paperwork is a byproduct of that, not a substitute for it, and it's worth building your product with that in mind from the start rather than reverse-engineering documentation after the fact. See what that looks like in practice on our services page.
This guide covers the general self-assessment path for connected devices under CRA and RED. It's not legal advice. For products in higher risk categories, or if you're unsure where your product falls, get advice specific to your situation.
Sources: CRA Regulation (EU) 2024/2847 - Annex III, Annex IV, Article 64; RED Delegated Regulation (EU) 2022/30; Commission Implementing Decision (EU) 2025/138 - EN 18031 harmonized standards
Denys Zaliznyak is the CTO of Platanor Technologies. Platanor builds the technical documentation, SBOM, and security architecture that CRA and RED conformity assessments require - delivered alongside production firmware, not as a separate paperwork exercise. platanor.com/contact