Think of CRA common specifications as the EU's official technical manual for digital product security. They are detailed technical standards drafted by the European Commission, which become legally mandatory whenever official harmonised standards aren't available or suitable.
These rules exist to ensure that all ‘products with digital elements’ meet a consistent, enforceable cybersecurity baseline before they can ever be sold on the EU market. For example, a common specification could dictate the exact encryption protocol a smart thermostat must use, turning a general security goal into a specific, testable engineering requirement.
Understanding the New Digital Rulebook
The Cyber Resilience Act (CRA) is a landmark regulation built to strengthen the security of practically every connected device and piece of software sold in the European Union. While the Act is great at laying out what security outcomes are required in its Annexes, it doesn’t always prescribe how to achieve them. That's where common specifications come in.
Let's say you manufacture a smart home security camera. The CRA obligates you to make it "secure by design", but what does that really mean in practice? It could involve specific encryption protocols, a secure update mechanism, or how you protect stored data.
The Role of Common Specifications
Common specifications fill in those technical details. They function as a critical fallback option for compliance. The default path to proving compliance is by following "harmonised standards" developed by European standardisation organisations. However, if those standards get delayed or simply don't cover a specific product, the European Commission can issue CRA common specifications directly.
Once issued, these specifications are not optional suggestions; they carry full legal weight. Adhering to them grants a "presumption of conformity," which is your official ticket to proving your product meets the CRA's essential security requirements.
This makes them a non-negotiable part of your strategy for gaining and keeping EU market access. If an applicable common specification exists for your product—like one for smart lighting systems—and you ignore it, your product cannot legally get the CE mark and will be barred from sale.
The timeline for these changes is closing in. The European Parliament approved the Cyber Resilience Act on March 12, 2024, and the regulation officially enters into force on December 10, 2024.
While most obligations begin on December 11, 2027, the duty to report actively exploited vulnerabilities kicks in much sooner, on September 11, 2026. This means you will need to send an early warning to ENISA within 24 hours of discovering such an issue. You can get more insights on the CRA's implementation from the European Cyber Security Organisation.
For manufacturers, importers, and distributors, the message is clear: the time to build a plan is now. Getting a handle on these rules is the first step toward a successful compliance strategy. For a complete overview of all the critical dates, check out our guide on CRA deadlines for 2025-2027.
Understanding the CRA Compliance Hierarchy
Navigating Cyber Resilience Act (CRA) compliance can feel like trying to follow a complex rulebook without a table of contents. This section provides that clarity, mapping out the clear hierarchy of rules you need to follow. It all starts with the CRA itself, which sets the foundational security principles.
The heart of these rules lives in Annex I of the Act, which lists the essential security requirements (ESRs). Think of these as high-level goals—like ensuring products are free from known exploitable vulnerabilities and are shipped with secure default settings. To prove you meet these ESRs, you have two main paths.
Harmonised Standards: The Primary Path
The main and preferred way to show compliance is by using harmonised standards. These are detailed technical specifications created by official European standardisation organisations (like CEN-CENELEC). When the European Commission formally approves and lists one of these standards in its Official Journal, it provides a massive benefit.
Following that standard gives your product a “presumption of conformity.” This means that if you build your product according to a relevant harmonised standard, it is automatically assumed to meet the specific ESRs covered by that standard. This is the most direct route. But what happens when these standards are delayed, or simply don’t exist for your product?
This is where the compliance hierarchy becomes crucial.
As the diagram shows, CRA common specifications are not just a suggestion; they are a direct and legally binding rulebook under the main Act, serving as a critical bridge to EU market access.
Common Specifications: The Mandatory Alternative
So, what happens when there's no harmonised standard? This is exactly where CRA common specifications come into play. They are the official fallback mechanism, ensuring there are no gaps in the regulatory framework that could leave product security to chance.
When the European Commission identifies a significant delay in standardisation or an urgent need for a rule, it can directly issue a common specification. Once published, this document is no longer a suggestion—it becomes the legally mandatory method for demonstrating conformity with the ESRs it addresses.
Following these specifications also grants your product a presumption of conformity, making them a non-negotiable part of your compliance journey. This process is a key element of the overall CRA conformity assessment, which ultimately determines if your product is legally ready for the market.
To understand how these documents work together, here's a simple breakdown of the CRA's document hierarchy.
CRA Compliance Document Hierarchy
Understanding the primary and secondary paths to demonstrating CRA conformity.
| Compliance Document | What It Is | Legal Status | Your Action |
|---|---|---|---|
| Harmonised Standard | A detailed technical specification from a European Standardisation Organisation (ESO). | Voluntary. Provides a presumption of conformity. | The primary path. If one exists for your product, follow it. |
| Common Specification | A technical specification published directly by the European Commission. | Mandatory. Required when no harmonised standard exists or is delayed. | The fallback path. You must follow it if one is issued for your product. |
This table clarifies that while harmonised standards are the preferred route, common specifications are the safety net that becomes a mandatory requirement when needed.
Practical Example: A Smart Security Camera
Let’s make this real. Imagine you manufacture a smart home security camera. The CRA's Annex I requires you to implement robust access control and protect the confidentiality of stored data. You check the EU's Official Journal, but there is no harmonised standard available for smart cameras yet.
In this scenario, the European Commission might issue a common specification for IoT security devices to fill the gap. This document would provide very concrete rules, such as:
- Requiring multi-factor authentication for all remote access.
- Mandating AES-256 encryption for all video footage stored on the device or in the cloud.
- Defining specific password complexity rules and banning weak default credentials like “admin/admin”.
To legally apply the CE mark and sell your camera in the EU, you must follow this common specification precisely. Your technical documentation would need to prove you have implemented these exact technical rules, not just the high-level goals of Annex I. This makes monitoring for the release of CRA common specifications a critical activity for every product team.
Who Is Impacted by Common Specifications
The Cyber Resilience Act spreads the burden of product security right across the supply chain, and CRA common specifications are no different. These aren't just technical rules for engineers; they create specific, legally-binding duties for every economic operator who has a hand in bringing a product to the EU market. Compliance is a team sport, and everyone has a distinct position to play.
Getting these roles right is absolutely vital. A single breakdown in the chain—from a design flaw to a distribution oversight—can lead to non-compliant products being sold. That means facing hefty financial penalties and having your market access pulled. Each party acts as a check on the others, creating a solid chain of custody for compliance.
The Role of Manufacturers
For manufacturers, the real work starts on day one. You are the one primarily responsible for making sure products meet all essential requirements, including any rules spelled out in applicable CRA common specifications. This isn't a box-ticking exercise; it's a responsibility that needs to be woven into the very fabric of your product lifecycle.
This means you must build these technical specifications directly into your product’s design, development, and production processes. This is the heart of the "secure by design" principle that the CRA demands. Simply testing for security at the end of the line won’t cut it. Security has to be a foundational piece from the first line of code.
A huge part of this is creating and maintaining the technical documentation, which includes the EU Declaration of Conformity. This declaration must clearly state which standards or CRA common specifications you used to prove compliance. For a deeper look at these duties, check out our complete guide on CRA manufacturer obligations.
The Role of Importers
Importers are the gatekeepers for any product entering the European Union from abroad. Your role isn't to create compliance, but to verify it. You have a legal duty to make sure any product you place on the EU market is fully compliant with the CRA.
Before bringing a product into the EU, an importer must confirm that the manufacturer has completed the necessary conformity assessment. This includes verifying that the technical documentation is complete and that the product bears the correct CE marking.
This verification is an active step, not a passive one. An importer has to actively check the manufacturer's Declaration of Conformity and see if it references the specific CRA common specifications required for that product. If that documentation is missing or looks incomplete, the importer cannot legally put the product on the market.
Practical Example: A Non-EU Smart Toy
Imagine a French company wants to import a new line of connected children's toys from a supplier in Asia.
- The importer checks if a common specification for children's IoT devices exists.
- If one does, they must get their hands on the manufacturer's EU Declaration of Conformity.
- They then verify that this declaration explicitly lists that specific common specification as the basis for compliance.
- Only after this confirmation can they legally import and sell the toys in France and across the EU.
The Role of Distributors
Distributors are the final link in the chain before a product hits the shelves and reaches the consumer. Your obligation is defined as exercising "due care." This doesn't mean you need to perform a full technical audit, but you absolutely must conduct reasonable checks for obvious signs of non-compliance.
A distributor’s responsibilities include:
- Checking for the CE mark: You must ensure the product and its packaging display a valid CE mark.
- Verifying Documentation: You need to confirm the product comes with the required instructions and safety information, written in a language consumers can easily understand.
- Acting on Suspicion: If you have any reason to believe a product doesn't conform to the CRA, you must not make it available on the market. You should immediately inform the manufacturer, the importer, and the market surveillance authorities.
For instance, a German distributor receiving a shipment of smart locks from a non-EU supplier has a duty to check for the CE mark. If they notice the manufacturer's documentation makes no mention of security at all, that's a major red flag. It should prompt them to question the product's conformity before ever putting those locks on store shelves.
What to Expect Inside a Common Specification Document
While the European Commission is still drafting the first official CRA common specifications, the Cyber Resilience Act’s essential security requirements give us a very clear blueprint of what’s coming. Don’t think of a common specification as a high-level suggestion. Think of it as a detailed technical manual for building a secure product, translating the CRA's abstract principles into concrete, mandatory engineering tasks.
These documents will be dense and specific, leaving little room for interpretation. To effectively analyse the technical requirements and obligations presented in these documents, it can be beneficial to employ tools that help you master document extraction with PDF parsers. This ensures you can quickly pinpoint every single obligation.
Core Components of a Common Specification
Based on the CRA's structure, we can expect these documents to be organised around four key pillars. Each one will lay out specific, measurable, and auditable rules that manufacturers absolutely must follow to claim conformity.
Specific Security Controls: This is where abstract goals become hard technical rules. For instance, instead of just saying “protect data,” a specification might mandate TLS 1.3 or higher for all data in transit and AES-256 encryption for all data at rest. No ambiguity.
Vulnerability Handling Processes: The document will define precise workflows for managing security flaws. It could set mandatory timelines, such as requiring critical vulnerabilities to be patched within 14 days of confirmation, and detail the exact information that must be shared in a coordinated disclosure.
Technical Documentation Requirements: It will specify exactly what you need to include in your technical file. This could mean stipulating the precise format for a Software Bill of Materials (SBOM), such as requiring SPDX or CycloneDX, and detailing every necessary field like component name, version, and supplier. You can learn more about getting this right in our guide on the CRA technical file structure.
Conformity Assessment Steps: The specification will outline the exact path to proving compliance. It will clarify when a manufacturer's self-assessment is sufficient versus when a third-party audit by a Notified Body is required, especially for any products deemed higher risk.
The urgent need for this level of clarity is underscored by a widespread awareness gap. A recent ONEKEY study revealed that only 32% of EU companies feel fully informed about CRA requirements, with just 14% having implemented extensive compliance measures. This gap highlights why detailed guidance in CRA common specifications is so crucial for businesses. You can discover more about these findings on ONEKEY.com.
Practical Example: A Smart Baby Monitor
Let's apply this to a real-world product: a connected baby monitor. If the European Commission issues a common specification for smart home monitoring devices, it wouldn't just suggest security features; it would mandate them with extreme precision.
A hypothetical specification for this baby monitor would likely transform abstract security principles into a concrete engineering checklist, covering everything from initial design to post-market support.
Here’s what that checklist might look like in practice:
Secure Access Controls:
- Requirement: All remote access must be protected by multi-factor authentication (MFA).
- Implementation: Your development team must integrate an MFA flow using a time-based one-time password (TOTP) app or SMS verification before any user can view the video stream from outside their home network. Default passwords like "admin" are explicitly forbidden.
Data Protection:
- Requirement: All video and audio streams must be encrypted end-to-end using a specified cryptographic protocol.
- Implementation: Your firmware engineers must implement AES-256 encryption for the video feed from the camera to the parent's viewing device, ensuring that not even the manufacturer can intercept the unencrypted stream.
Firmware Updates:
- Requirement: A secure and automated mechanism for over-the-air (OTA) updates must be provided for the product's supported lifetime.
- Implementation: You must build a system where firmware updates are cryptographically signed. The device has to verify this signature before installation to prevent malicious updates, and users must be automatically notified when a new security patch is available.
This example shows exactly how CRA common specifications will close the gap between regulatory goals and engineering reality. They will provide the explicit, non-negotiable rules needed to build a verifiably secure product for the EU market.
Your Action Plan for CRA Compliance with Regulus
Knowing the Cyber Resilience Act's rules is one thing. Actually implementing them across an entire product portfolio is another challenge altogether. This is where you move from theory to a practical, step-by-step strategy. Let’s walk through how to use Regulus to turn the complex web of regulations, including the future CRA common specifications, into a manageable project.
The first hurdle in any compliance journey is simply figuring out what's in scope. Regulus automates this applicability assessment, quickly identifying which of your products fall under the CRA's wide net. That step alone can cut out weeks of manual work, giving you immediate clarity on where to focus your resources.
From Classification to Actionable Requirements
Once you know which products are in scope, the next job is classification. Regulus helps you determine if a product is "Default" or fits into a "Critical" class (Class I or Class II). This is a crucial distinction, as it dictates the rigour of your conformity assessment. But the platform doesn't stop there; it automatically maps the corresponding obligations from Annex I directly to your portfolio.
This mapping is designed to be dynamic. As the European Commission publishes new CRA common specifications, Regulus incorporates their detailed technical rules straight into its requirements matrix. This ensures your engineering and compliance teams are always working from the most current, legally binding rulebook.
Regulus bridges the gap between high-level regulatory text and day-to-day engineering tasks. It translates abstract legal obligations into a concrete checklist of technical and procedural controls for each product.
This approach is your safety net against overlooking a critical requirement buried deep within a newly issued specification—a common and costly pitfall for teams relying on manual tracking.
Mastering Documentation and Vulnerability Reporting
One of the CRA's biggest operational headaches is documentation. Regulus tackles this head-on by generating ready-to-use technical file templates that align with Annex II. These templates come pre-structured to include the evidence needed to prove you conform with Annex I and any applicable CRA common specifications.
Managing these evolving specifications demands a clear strategy. Your action plan must cover not just understanding the content but also continuously managing changes. A key part of this is learning how to implement robust document version control best practices.
The CRA also brings an extremely tight 24-hour deadline for reporting actively exploited vulnerabilities. The Regulus vulnerability management framework gives you clear guidance on setting up the detection, triage, and reporting workflows needed to meet this demanding timeline. It helps you organise the necessary processes and documentation for ENISA notifications, turning a potential crisis into a structured, predictable response.
Building Your Roadmap for 2026 and Beyond
The stakes here are incredibly high. Europe's cybersecurity market is projected to hit 42.37 billion EUR in 2024, a figure driven heavily by new regulations. With fines for CRA non-compliance reaching up to €15 million or 2.5% of worldwide turnover, and only 14% of firms deeply engaged in implementation, having the right tools is no longer optional—it's essential for market access.
Ultimately, Regulus provides a clear and comprehensive roadmap to meet the 2026 and 2027 deadlines. By unifying every step of the compliance process, the platform transforms a daunting regulation into a predictable and achievable project.
Here’s how Regulus streamlines your journey:
- Automated Scoping: Instantly identifies which products are subject to the CRA.
- Intelligent Classification: Helps categorise your products and maps the exact obligations.
- Dynamic Requirement Updates: Integrates new CRA common specifications as they are released.
- Template Generation: Provides pre-built templates for your Annex II technical file.
- Vulnerability Workflow Guidance: Prepares you for the strict 24-hour reporting deadline.
By using a structured platform, you move beyond spreadsheets and guesswork. You gain a clear, centralised view of your compliance status, empowering your organisation to place products on the EU market with confidence.
Your Practical Compliance Checklist for 2026 and Beyond
With the Cyber Resilience Act timelines now firm, it’s time to shift from understanding the regulation to taking concrete action. This straightforward checklist breaks down your preparation into clear, time-bound steps. Think of it as a roadmap for turning the complex demands of the CRA and its associated CRA common specifications into manageable tasks.
The journey starts now. Waiting for the deadlines to get closer isn’t a viable strategy; proactive preparation is the only way to ensure you maintain uninterrupted market access.
Immediate Actions Before 2026
The first phase is all about getting a complete and accurate picture of your product landscape. You can't secure what you don't know you have. This foundational work is non-negotiable and sets the stage for everything that follows.
Create a Product Inventory: Start by cataloguing every single product with digital elements you currently sell or plan to bring to the EU market. For a software company, this means listing every application, library, and microservice. For a hardware company, it means every smart device, down to the firmware version. Your list needs to be exhaustive.
Assign Clear Ownership: For each product on your list, assign a specific owner or team who is responsible for its CRA compliance journey. For example, the product manager for your flagship 'SmartCam Pro' should be the designated CRA owner for that device, coordinating with engineering and legal. Accountability is what drives progress.
Key Milestones for 2026
As the first major deadline approaches, your focus needs to shift from inventory to formal assessment and planning. This is where the high-level requirements of the CRA begin to translate into specific engineering and process tasks.
By the end of 2026, your organisation should have moved past initial discovery and be deep into the specifics of classification and requirement mapping. The September reporting deadline means vulnerability handling processes must be functional and tested well in advance.
By Q4 2026: Conduct a Formal CRA Applicability Assessment
For every product in your inventory, you need to perform and document a formal assessment to confirm it falls under the CRA. This step provides the official basis for your compliance programme and is a critical piece of evidence for any audit.
By September 2026: Implement and Test Your Vulnerability Handling Process
The 24-hour incident notification requirement for actively exploited vulnerabilities kicks in on 11 September 2026. Your process for detecting, triaging, and reporting incidents to ENISA must be fully implemented and stress-tested long before this date. For example, you should run a simulation where a critical vulnerability is "discovered" in your smart speaker, and your team must successfully draft and "submit" a report to a mock ENISA portal within 24 hours.
Final Preparations for 2027
This is the final stretch before the CRA applies in full force. Your activities should now be centred on detailed implementation, documentation, and continuous monitoring to ensure you’re ready for full enforcement.
By Q1 2027: Classify Products and Map Requirements
Classify each of your products (Default, Critical Class I, or Critical Class II) and start mapping the specific Annex I requirements to your development lifecycle. This involves translating legal obligations into concrete technical controls.Ongoing Task: Monitor for New Standards and Specifications
Actively monitor the EU Official Journal for any new harmonised standards and CRA common specifications that apply to your product categories. This isn't a one-time check; it demands a continuous process. For example, a dedicated compliance manager or an automated tool should check for new publications weekly and alert the relevant product teams if a new specification for "home automation controllers" is released.
Frequently Asked Questions About CRA Common Specifications
As product managers, compliance officers, and engineers dig into the Cyber Resilience Act, some questions come up again and again. These usually centre on the practical side of CRA common specifications—what they are, how they work, and what they mean for your business.
This section tackles those common queries head-on, giving you the direct answers you need to build a clear compliance strategy.
What Happens If a Harmonised Standard Is Published After We Comply?
This is a great question and a very real scenario. If a harmonised standard is published and cited in the EU's Official Journal, it will override the existing common specification for that product family. From that point on, complying with the new harmonised standard becomes the default way to prove your product meets the CRA's essential requirements.
The good news is that the CRA is built for this. The regulation will provide for transitional periods, giving manufacturers time to manage the shift. Your job will be to have a solid process for monitoring the EU's Official Journal for these updates and a plan to move your products over to the new standard.
This dynamic highlights a critical point: compliance isn't a one-off check. Your processes must be built to adapt as the regulatory landscape evolves.
Are Common Specifications the Same for All Products?
Not at all. They are designed to be highly specific, targeting the unique risks of particular product categories. A one-size-fits-all approach just wouldn't work for cybersecurity. The rules for a smart thermostat, for instance, will look very different from those for an industrial controller or a connected toy.
For example, a common specification for a smart lock might focus heavily on physical tamper resistance and access control logs. In contrast, one for a photo editing software might prioritize rules around secure handling of personal data and protection against malicious file uploads.
How Can a Small Business Afford to Comply?
The EU has recognised that compliance costs are a real concern, especially for smaller businesses. The goal of the CRA is to lift the security baseline for everyone, not to squeeze small and medium-sized enterprises (SMEs) out of the market. While the rules apply to all manufacturers, the path to compliance doesn't have to rely on expensive consultants.
For an SME, the most cost-effective strategy is to adopt a structured, tool-driven approach. A dedicated compliance platform offers a much more affordable path forward. It gives smaller teams clear, step-by-step guidance on their obligations, generates the right documentation templates, and helps build a solid compliance plan without a massive upfront investment. This makes an audit-ready programme accessible for any business, turning a complex regulatory demand into a manageable project.
Ready to turn CRA complexity into a clear, actionable plan? Regulus is the software platform designed to guide you through every step of the Cyber Resilience Act. From applicability assessments to requirement mapping and technical file generation, we help you meet your obligations and confidently place compliant products on the EU market. Discover how Regulus can support your compliance roadmap at https://goregulus.com.
