The CRA standardisation request is the European Commission's official instruction to Europe’s main standardisation bodies: CEN, CENELEC, and ETSI. In simple terms, it's the kick-off for creating the detailed technical rulebooks—called harmonised standards—that will define how manufacturers can meet the legal duties of the Cyber Resilience Act. Following these standards will give you a clear, recognised path to proving compliance.
Decoding the CRA Standardisation Request
Think of the Cyber Resilience Act (CRA) itself as a high-level goal. It tells you what you need to achieve—for example, that your product must be secure and resilient. But it doesn't specify the exact technical details of how to get there. It won't tell you precisely how to implement a secure update mechanism or what a "secure default configuration" looks like in practice.
This is where the standardisation request comes in. It's the official job order from the European Commission to the technical experts who write the rulebooks for product safety in Europe:
- CEN (European Committee for Standardization)
- CENELEC (European Committee for Electrotechnical Standardization)
- ETSI (European Telecommunications Standards Institute)
These organisations are now tasked with turning the CRA's high-level legal requirements into concrete, practical, and technical specifications. They are writing the "how-to" manuals.
The Power of Presumption of Conformity
The single biggest reason these standards matter is the "presumption of conformity." It’s a powerful legal concept. It means that if you design and build your product following the relevant harmonised standards, market authorities will automatically presume your product complies with the CRA's essential requirements.
This provides the clearest, most direct, and most defensible route to demonstrating compliance. It takes the guesswork out of the equation.
For instance, the CRA demands that manufacturers handle vulnerabilities effectively. Instead of leaving you to figure out what "effectively" means, a harmonised standard will likely lay out a specific process for vulnerability intake, triage, and patching, probably based on established best practices like ISO/IEC 29147. By following that standard, you get a ready-made methodology that is officially recognised across the EU.
A standardisation request is not just a polite suggestion; it's a formal mandate. It triggers a structured process that bridges the gap between high-level law and the real-world engineering needed to build secure products.
This whole system is designed to make market access simpler. By sticking to a single set of harmonised standards, you avoid the nightmare of trying to meet different interpretations of the law in different EU countries. It creates one unified benchmark for security, giving you the confidence to build, document, and sell your product on the European market. A crucial part of this is getting your paperwork in order. You can get a head start by learning how to prepare your CRA technical documentation in our detailed guide.
The Key Players: CEN, CENELEC, and ETSI Explained
To get ready for the Cyber Resilience Act, you first need to understand the organisations writing the detailed rules. The European Commission has sent a formal CRA standardisation request to a trio of specialised bodies known as the European Standardisation Organisations, or ESOs.
Think of them as a team of expert architects, each with a distinct speciality, working together to build a secure foundation for Europe’s digital market. These three key players are CEN, CENELEC, and ETSI. Each brings a unique focus to the table, ensuring the resulting harmonised standards are both comprehensive and technically sound. Their collaboration is what turns the CRA's legal principles into practical, engineering-focused guidelines.
CEN: The Generalist Architect
The European Committee for Standardization (CEN) is the architect for a huge range of non-electrical products and services. Its scope is incredibly broad, covering everything from children's toys and medical devices to construction materials and mechanical engineering.
In the context of the CRA, CEN will concentrate on the cybersecurity aspects of products that fall outside the specific domains of its two counterparts.
Practical Example of CEN's Scope:
- A manufacturer of smart locks for doors would look to CEN for standards on physical security combined with digital access control. CEN would handle the non-electrical aspects, like how the lock's software interfaces with its mechanical parts securely.
- Connected gym equipment, like a smart treadmill, would also fall under CEN, which would define standards for the secure software that controls the machine’s functions and stores user data.
CENELEC: The Electrical Specialist
The European Committee for Electrotechnical Standardization (CENELEC) is the specialist for all things electrical and electronic. This organisation is responsible for creating standards for a massive array of products that use electricity, from everyday gadgets to complex industrial systems.
Practical Examples of CENELEC's Scope:
- Smart Home Devices: Think of smart coffee makers, connected lighting systems, or intelligent thermostats. CENELEC will define the cybersecurity standards to protect these devices from being compromised.
- Industrial Control Systems (ICS): In factories and power plants, CENELEC’s standards will ensure the electrotechnical components of operational technology (OT) are secure against cyber threats.
For the CRA, CENELEC’s role is critical. Its work will directly shape the security requirements for a huge number of IoT products and connected hardware, making sure they are resilient by design.
ETSI: The Communications Expert
The European Telecommunications Standards Institute (ETSI) handles the communications side of technology. This includes everything related to information and communication technologies (ICT), like mobile networks, radio equipment, and the internet.
ETSI's expertise is vital for the CRA because nearly all "products with digital elements" communicate in some way.
Practical Example of ETSI's Scope:
- Wireless Security Protocols: When a connected car communicates with roadside infrastructure (V2X), ETSI standards define the secure communication protocols to prevent hijacking or data interception.
- IoT Network Interfaces: For a smart water meter sending data over a Low-Power Wide-Area Network (LPWAN), ETSI's work ensures the radio interface is secure and the data transmission is encrypted.
ETSI develops the standards that ensure these communications are secure and reliable. For example, when your IoT device sends data to the cloud, ETSI's standards will help define the protocols and security measures needed to protect that data in transit.
This collaborative structure is governed by Regulation (EU) No 1025/2012, which sets out how the ESOs receive mandates to support EU law. The process is remarkably efficient; research shows that one European Standard replaces 34 national standards, drastically reducing market fragmentation. This unified approach is a major benefit for manufacturers, as it cuts through red tape and simplifies market access across the entire EU.
You can check out our guide on how the CRA conformity assessment works to understand this process better.
The ESOs are central to putting EU legislation into practice. About 30% of all European Standards published by CEN and CENELEC come from specific requests by the European Commission. This highlights their role in creating actionable rules that support regulatory goals for the 34 countries in the European economic area. You can delve deeper into the support for standardisation activities to see the scale of this collaboration.
How The Standardisation Process Works In Practice
So, how does a dense legal text like the Cyber Resilience Act get translated into a set of technical standards that engineering teams can actually use? The process is surprisingly structured, and understanding it gives you a roadmap for when you can expect crucial guidance to land.
It all kicks off with a formal CRA standardisation request from the European Commission. Think of this as the starting gun. This document officially tasks the European Standardisation Organisations (ESOs) – CEN, CENELEC, and ETSI – with developing the specific standards needed to support the Act, complete with topics to cover and deadlines.
From Request To Committee
Once the ESOs accept the request, the real work begins. The task is handed over to specialised Technical Committees (TCs) or, in many cases, Joint Technical Committees (JTCs). These committees are the engine room of the whole operation, made up of industry experts, national delegates, and other stakeholders who bring hard-won, real-world experience to the table.
For instance, a Joint Technical Committee is the perfect vehicle for tackling topics that cut across different domains, like the cybersecurity of industrial machines, which involves both electrical (CENELEC) and non-electrical (CEN) expertise. These experts don't start from scratch. Their first move is almost always to review existing international standards, like those from ISO/IEC, to see what can be adapted. This ensures that the new European standards are as globally aligned as possible.
We saw this exact process play out with the recent Data Act. The Commission issued Mandate M/614, which CEN and CENELEC officially accepted on July 7. This set in motion a commitment to deliver seven European standardisation deliverables—including four European Standards and three Technical Specifications—to support the Act's application from September 12, 2025. You can read more about how the Data Act standardisation request is accelerating digital regulation.
Drafting And Public Consultation
The committee’s first major task is to hammer out a working draft. This initial version is debated, refined, and edited over many sessions, drawing on the collective knowledge of the group.
Crucially, this isn’t a closed-door affair. The process includes a vital stage known as the ‘public enquiry’ or public comment period. During this window, the draft standard is shared with national standards bodies and the public for feedback.
This is a critical opportunity for your company to have a voice. By engaging through your national standards body, you can provide feedback to ensure the final rules are practical and don’t impose an unworkable burden on your industry.
For a CRA-related standard on vulnerability reporting, for example, the draft would likely be scrutinised by security researchers, product managers, and software developers. Their input could be invaluable in fine-tuning the requirements to be both effective against threats and feasible to implement in a fast-paced development cycle.
The following infographic gives a great visual of how input from 34 national bodies is consolidated into a single, unified European Standard.
This highlights the core efficiency of the European model: creating one harmonised standard that replaces dozens of potentially conflicting national rules.
Final Approval And Publication
After the public enquiry closes, the technical committee gets back to work, reviewing every single comment and making revisions. This phase often involves some intense negotiation to strike a consensus that balances security, innovation, and commercial reality.
Once consensus is reached, the final draft goes to a formal vote. To pass, it needs approval from a weighted majority of the national standards bodies that make up CEN and CENELEC. After a successful vote, the document is published as an official European Standard (EN). Its reference is then published in the Official Journal of the European Union (OJEU), giving it legal force. This is the moment it becomes a "harmonised standard," an officially recognised tool you can use to claim "presumption of conformity" with the law.
To help you anticipate these key milestones, the table below provides a simplified overview of the journey from a standardisation request to a published harmonised standard.
CRA Standardisation Timeline From Request to Harmonised Standard
A simplified overview of the key phases in the development of harmonised standards for the Cyber Resilience Act, helping teams anticipate key milestones.
| Phase | Description | Typical Duration | Key Output |
|---|---|---|---|
| Request & Acceptance | European Commission issues a request; ESOs formally accept it and assign it to a Technical Committee. | 2-4 months | Accepted mandate and work plan. |
| Drafting | The Technical Committee develops the initial working draft of the standard based on the mandate and existing work. | 6-12 months | First stable draft for review. |
| Public Enquiry | The draft is circulated to national bodies and the public for comments and feedback. | 2-3 months | Collection of all stakeholder feedback. |
| Revision & Consensus | The committee reviews all comments, revises the draft, and works to achieve consensus among members. | 4-6 months | Final draft for voting. |
| Formal Vote | National standards bodies vote on the final draft. A weighted majority is needed for approval. | 1-2 months | Approved final standard text. |
| Publication | The standard is published as an EN, and its reference is published in the Official Journal of the EU (OJEU). | 1-2 months | A published harmonised standard (EN). |
As you can see, the path is methodical and designed to build consensus. While it can feel slow, each step is essential for creating standards that are both robust and practical for the market.
Predicting the Future CRA Harmonised Standards
While we’re all waiting for CEN, CENELEC, and ETSI to publish the final CRA standardisation request, we’re not exactly flying blind. By carefully analysing the CRA’s Annex I requirements and looking at well-established international security frameworks, we can make some highly educated predictions about what these new standards will contain. This gives your product security teams a powerful head start on compliance.
Think of it as a weather forecast for your regulatory roadmap. We can already see the major fronts moving in and can tell which areas will be most affected. This lets us prepare our defences long before the storm actually hits. The key thing to remember is that the standards bodies won't be reinventing the wheel; they will build upon globally recognised best practices that already exist.
For manufacturers, this means you can start aligning your internal processes today. You don't have to wait for the final text to begin building a security-first culture that maps directly to the CRA's core principles.
The Secure Development Lifecycle Framework
One of the most predictable areas for standardisation is the Secure Development Lifecycle (SDLC). The CRA’s Annex I states that products must be "designed, developed and produced" to ensure an appropriate level of cybersecurity. A formal standard will turn this high-level principle into a concrete, auditable process.
It’s almost a given that this new standard will draw heavily from existing frameworks, particularly IEC 62443-4-1. This is already a mature set of process requirements for the secure development of industrial automation and control systems, making it a perfect foundation.
Practical Example:
Imagine a manufacturer of smart industrial sensors that currently has a fairly informal development process. To get ahead, they can start adopting practices from IEC 62443-4-1 right now. This could include:
- Establishing a formal threat modelling process for every new feature.
- Implementing static and dynamic code analysis tools in their CI/CD pipeline.
- Documenting all security testing and verification procedures.
By doing this now, they are effectively building the evidence needed to demonstrate compliance with the future harmonised standard. With the formal adoption of the CRA fast approaching, it's wise to get familiar with the key CRA deadlines between 2025 and 2027 in our dedicated article.
Vulnerability Handling and Disclosure
Another key area laid out in Annex I is the manufacturer's ongoing responsibility for vulnerability management. This covers everything from how you handle discovered vulnerabilities internally to how you disclose them responsibly to the public. The future standards are almost certain to be based on two key ISO/IEC standards.
- ISO/IEC 29147: This standard is all about vulnerability disclosure. It provides a clear framework for how to receive, assess, and communicate vulnerability information with researchers and users.
- ISO/IEC 30111: This one is the internal counterpart, focusing on vulnerability handling processes. It details the steps a manufacturer should take from the moment a flaw is discovered to when it's fixed.
Practical Example:
A company making a consumer-facing smart camera can align with these standards by:
- Publishing a Vulnerability Disclosure Policy (VDP) on their website, providing a clear email address (e.g., security@company.com) for researchers to submit findings.
- Setting up an internal ticketing system (like Jira) to track reported vulnerabilities from intake, through triage and engineering, to patch release, mirroring the process flow in ISO/IEC 30111.
- Coordinating with the researcher who found the bug to agree on a public disclosure date, following the guidelines in ISO/IEC 29147.
By aligning your internal vulnerability management programme with these two standards today, you are essentially pre-complying with the CRA. It ensures your processes for intake, triage, remediation, and disclosure will meet the expectations of market surveillance authorities.
Software Bill of Materials Requirements
The CRA makes it a legal requirement for manufacturers to create and maintain a Software Bill of Materials (SBOM) as part of their technical documentation. While the Act just says it must be in a "commonly used, machine-readable format," the harmonised standards will nail down the specific details.
It's a near certainty that the new standard will formalise the use of the two dominant industry formats:
- SPDX (Software Package Data Exchange): An open standard for communicating SBOM information that excels at tracking licensing and provenance details. It’s already recognised as an international standard, ISO/IEC 5962.
- CycloneDX: A lightweight, security-focused SBOM standard from OWASP, specifically designed for easy integration into automated security tools.
Practical Example:
A company producing a smart home hub can prepare by integrating SBOM generation directly into its build process. Using open-source tools, they could automatically generate an SBOM in both SPDX and CycloneDX formats for every software release. This file would list all open-source libraries, their versions, and their dependencies, creating the exact "ingredients list" the CRA demands.
By taking these predictive steps, you transform compliance from a last-minute, reactive scramble into a proactive, strategic part of your business. You build resilience directly into your products and processes, turning regulatory uncertainty into a tangible competitive advantage.
Your Action Plan for CRA Compliance
Turning the legal language of the Cyber Resilience Act into a concrete engineering plan can feel overwhelming, especially while the harmonised standards are still being written. But here’s the reality: waiting for CEN, CENELEC, and ETSI to publish the final rules isn't a strategy. It’s a gamble. Getting ahead of the curve now is how you turn this regulatory challenge into a genuine competitive edge.
The whole point of using harmonised standards, once they're available, is to gain the ‘presumption of conformity’. This is your simplest and most direct path to putting a CE mark on your product and selling it in the EU. If you decide to go your own way, the burden of proof is entirely on you to demonstrate that your alternative methods satisfy the CRA's essential security requirements—a path filled with complexity and legal risk.
This section lays out a practical, step-by-step plan to get your compliance journey started today. It’s all about turning regulatory theory into a structured, manageable process.
Step 1: Map Your Processes Against Annex I
Your first, and most important, job is to treat the CRA’s Annex I as your roadmap. The essential requirements laid out there are the bedrock of the entire regulation. No matter what the final standards say, your products must meet these obligations.
Start by conducting a gap analysis. Go through each requirement in Annex I and map your current development, security, and post-market surveillance processes against it. This simple exercise will immediately show you where you’re strong and where you’re falling short.
The goal here isn't to be perfect overnight. It's to create an honest baseline. Document where your processes already align and, more importantly, where the gaps are. This documented analysis becomes the foundation of your compliance plan.
For example, Annex I demands that products are shipped with a secure default configuration. Your mapping exercise should prompt questions like:
- Do we have a documented process for defining what "secure by default" actually means for our products? (e.g., all unnecessary ports closed, default passwords banned).
- Is this configuration tested and verified before every release?
- How do we make sure this secure configuration isn't compromised by future updates?
This kind of proactive mapping builds the internal evidence you'll need to produce later.
Step 2: Start Organising Your Technical Documentation Now
Don't wait for the harmonised standards to be finalised before you start building your technical documentation. The CRA already spells out the required structure, so you can build that framework today and use placeholders for the specific evidence you'll add later.
Here's a practical example. A smart lock manufacturer knows they need to demonstrate a solid vulnerability management process. Even without the final standard, they can start organising their evidence right now.
- Document What Exists: They can document their current system for receiving vulnerability reports, their triage methods, and their patching process.
- Create Placeholders: In their technical file, they can create a section titled "Vulnerability Handling (Annex I, Part 2)" and drop in their current process documents.
- Spot the Gaps: This immediately shows them what’s missing, like a formal Coordinated Vulnerability Disclosure (CVD) policy. Now they have a clear action item to work on.
By organising documentation early, you create a living file that evolves as the standards become clear. It's far less painful than trying to generate years of evidence from scratch when the deadline is looming. You can learn more about how to obtain a CE certificate for the CRA and the critical role documentation plays in our detailed guide.
Manufacturer's CRA Preparedness Checklist
To help you get started, here's a checklist of concrete actions your team can take right now. This isn't about boiling the ocean; it's about taking the first practical steps on the road to compliance.
| Action Item | Why It Matters | First Step to Take |
|---|---|---|
| Appoint a CRA Lead | Compliance needs a clear owner. This person will coordinate efforts across engineering, legal, and product teams. | Identify a senior individual with the authority to drive cross-functional initiatives. |
| Inventory Your Products | You can't comply if you don't know what's in scope. You need a full list of products with digital elements. | Create a spreadsheet listing all hardware and software products sold in the EU. |
| Analyse Annex I Gaps | This is the core of your initial assessment, showing you exactly where to focus your resources first. | Schedule a workshop with your development leads to review Annex I, requirement by requirement. |
| Draft an SBOM for one product | The SBOM is a key deliverable. Creating one now helps you understand the tooling and process effort required. | Choose a representative product and use an open-source tool to generate a preliminary SBOM. |
| Review Your VULN Process | Vulnerability handling is a non-negotiable part of the CRA. Your process needs to be documented and effective. | Document your current process for receiving, triaging, and patching vulnerabilities. |
| Identify Your National Body | Engaging with standardisation gives you a voice and early insights. | Search for your country's national standards body (e.g., UNE, DIN, BSI) and find their contact for EU technical committees. |
This checklist turns the abstract requirements of the CRA into a manageable project plan. By starting with these small, tangible wins, you build the momentum needed for the larger compliance effort.
Step 3: Engage With the Standardisation Process
The CRA standardisation request has kicked off a massive collaborative effort across Europe, and your organisation can—and should—have a voice in it. The standards are being hammered out in technical committees at CEN, CENELEC, and ETSI, all with input from national standards bodies.
Find your country's national standards body (like UNE in Spain, BSI in the UK, or DIN in Germany) and get involved. When your experts participate, they can offer feedback on drafts, helping to ensure the final rules are practical and don't create an impossible burden for your industry.
This whole framework is part of a well-established EU strategy under Regulation (EU) No 1025/2012. Historically, about 30% of standards are created specifically to support legislation, directly impacting businesses in the ES-region via 43 national members across 34 countries. The efficiency is undeniable: one European Standard replaces 34 separate national ones. This model is being actively funded, with the 2025 EISMEA call earmarking €7,851,000 for 27 topics. It reflects the progress we saw with the Data Act, where Mandate M/614 is set to produce seven deliverables by September 12, 2025—a clear blueprint for the CRA to follow. You can find more insights about European standardisation on cencenelec.eu.
As you build out your action plan, think about incorporating ideas from Actionable Compliance Training Best Practices to make sure your entire team is ready. Getting involved in the process doesn't just let you influence the outcome; it gives you a valuable early look at where the requirements are heading. This proactive stance transforms compliance from a reactive burden into a strategic advantage.
Frequently Asked Questions
As the Cyber Resilience Act moves closer to full enforcement, manufacturers are understandably full of questions. The role of the CRA standardisation request and the work being done by CEN, CENELEC, and ETSI are at the centre of many of these conversations.
Here are some clear, straightforward answers to the questions we hear most often.
When Will The Final CRA Harmonised Standards Be Published?
There isn't a single, fixed publication date, but the standardisation machine is definitely in motion. Typically, it takes about 18 to 24 months to develop harmonised standards from the moment a request is issued.
We expect to see drafts for the main horizontal standards popping up throughout 2025. The goal is to have the final, published versions ready by late 2026.
Given that the CRA becomes fully applicable in late 2027, this timeline is tight, but it has to be. Keep a close eye on updates from CEN, CENELEC, and ETSI. Even the early drafts will give you huge clues about where the final requirements are heading.
Is It Mandatory To Use Harmonised Standards?
No, you aren't legally forced to use the harmonised standards. However, doing so gives you a massive advantage called the "presumption of conformity."
Think of it as the official, pre-approved path to compliance. It’s the simplest and least risky way to prove your product meets the CRA’s rules.
If you decide to go your own way, the burden of proof is all on you. You'll need to create a mountain of documentation to convince regulators that your custom solutions are just as good as what the standards require. For example, instead of following a harmonised standard for secure updates, you'd have to write a detailed technical justification explaining why your proprietary update mechanism provides an equivalent level of security, complete with risk assessments and independent test results. This path is far more work, more expensive, and carries a much higher legal risk if a market surveillance authority comes knocking.
How Can My Company Influence The New CRA Standards?
You absolutely can have a say in how these standards are written. The best way is to get involved with your national standardisation body (like UNE in Spain, DIN in Germany, or AFNOR in France).
These national bodies are the members of CEN and CENELEC. They send their experts to sit on the technical committees that actually write the standards.
By joining and participating, your company's experts can give direct feedback on drafts. This is your chance to make sure the final rules are practical, technically sound, and don't create impossible hurdles for your industry. For example, if a draft standard proposes a 24-hour patching deadline for critical vulnerabilities, a company representative on the committee could argue that a 72-hour window is more realistic for complex embedded systems, providing data to back up their case. It’s a direct line to shaping the regulations you'll have to live by.
What Should We Do Before The Standards Are Available?
Sitting on your hands and waiting for the final standards to drop is not a winning strategy. Right now, your compliance work has to be based on the legal text of the CRA itself, especially the essential requirements in Annex I.
Start by documenting how you interpret those requirements and the specific security measures you're putting in place. A great way to get your organisation ready is by looking at existing, solid frameworks. For example, a practical guide to ISMS Standards ISO 27001 can give you a proven blueprint for building an effective security posture.
This proactive work builds a strong compliance foundation. When the new standards are finally released, you can quickly map what you've already done to the official requirements, saving yourself a world of time and stress.
The Cyber Resilience Act introduces complex new obligations for manufacturers. Instead of navigating vague requirements with spreadsheets and expensive consultants, let Regulus provide clarity. Our platform automates applicability assessments, maps your specific obligations, and provides a step-by-step roadmap to get your products ready for the EU market. Gain confidence and ensure your products are compliant by visiting https://goregulus.com.
