CRA Basics
-
Achieve CRA Cryptographic Key Management Requirements
Your firmware team thought the hard part was signing releases. Your compliance lead thought the hard part was building the technical file. Then the CRA review starts, and both teams realise the fundamental issue sits underneath everything else: who controls the keys, where they live, how they’re used, and whether you can prove it. That…
-
Mastering CRA Secure Update Architecture Requirements
An engineering lead opens the current OTA design and sees the gap immediately. Updates are downloaded over a protected channel, but rollback is manual. The signing key lives in a build server, not hardened key storage. The device can install a bad image and fail in a way that needs physical recovery. User notifications are…
-
CRA Coordinated Vulnerability Disclosure Policy Template
Your product manager has the CRA open in one tab, your generic security inbox in another, and a growing sense that the old process will not survive legal review. That reaction is warranted. Many teams already have something they call vulnerability disclosure. Usually it is an email alias, an internal Slack channel, and a rough…
-
CRA Vulnerability Handling Records Audit Trail: A 2026 Guide
If you are responsible for product security, there is a good chance your current process still relies on a mix of Jira tickets, scanner exports, release notes, and a spreadsheet someone updates when an auditor asks awkward questions. That setup can work for internal coordination. It does not work as a CRA vulnerability handling records…
-
CRA conformity documentation retention period: 2026
You already have products shipping into the EU, firmware releases queued, and a documentation trail spread across Jira tickets, build logs, shared folders, vendor emails, and whatever someone exported before they left the team. That is the starting point for the CRA conformity documentation retention period. Not a clean legal memo. A messy operational reality.…
-
CRA Log Integrity Tamper Resistance Explained
Under the EU’s Cyber Resilience Act (CRA), what used to be a technical best practice for product logs is now a non-negotiable legal mandate. CRA log integrity tamper resistance means you must be able to prove that security-related event logs on your product cannot be altered or deleted. This requirement is all about ensuring a…
-
CRA Open Source Steward Obligations Explained
The EU’s Cyber Resilience Act (CRA) creates specific CRA open-source steward obligations, but here’s the crucial detail: these rules only apply to legal entities like foundations or companies that systematically support open-source software used in commercial products. Individual developers, hobbyists, and non-commercial projects are explicitly exempt. What the CRA Means for Open-Source Projects The central…
-
CRA vs RED Cybersecurity Requirements: A Clear Comparison for 2026
For manufacturers of connected devices, figuring out how the Cyber Resilience Act (CRA) and the Radio Equipment Directive (RED) fit together is now a critical task. The core difference is one of scope. RED’s cybersecurity rules are specific to radio equipment, while the CRA casts a much wider net, covering nearly all products with digital…
-
CRA vs NIS2 Differences A Guide to EU Cyber Compliance in 2026
At first glance, the Cyber Resilience Act (CRA) and the NIS2 Directive might seem to cover similar ground. Both are powerful EU laws designed to bolster cybersecurity, but they approach the problem from fundamentally different directions. Understanding their distinct scopes is essential for any business operating in or selling to the EU. The core difference…
-
Your Guide to a Compliant CRA End of Life Security Updates Policy
An effective end-of-life (EOL) security updates policy is more than just a document; it’s a public commitment to your customers and a core obligation under the EU’s Cyber Resilience Act (CRA). You’re now required to provide security patches for a defined period, even after a product is no longer for sale. This policy must guarantee…
-
CRA Security Support Period Definition Explained for 2026
The CRA security support period is the legally mandated timeframe where you, the manufacturer, must provide free and timely security updates to fix vulnerabilities after your product is on the market. Think of it as a cybersecurity warranty that’s no longer optional. It shifts security from a value-add feature to a fundamental obligation for accessing…
-
CRA Notified Body Requirements: Your Path to Certification in 2026
The Cyber Resilience Act (CRA) is completely changing the game for digital product security in the EU, and Notified Bodies are the new gatekeepers. For manufacturers of higher-risk products, these organisations aren’t consultants—they are independent, state-appointed auditors for your product’s cybersecurity. They don’t help you build a compliant product. They verify that what you’ve built…
-
CRA Remote Data Processing Solutions Scope Explained
Figuring out if your remote solution falls under the EU’s Cyber Resilience Act (CRA) is a major question for manufacturers. The short answer is this: if a remote data processing solution is essential for a product’s main function, it’s almost certainly within the CRA remote data processing solutions scope. The physical product and its necessary…
-
Your Guide to CRA CE Marking Requirements
For years, the CE mark on a product has been a quiet symbol of trust. It tells you a device meets the EU’s essential health, safety, and environmental standards. But with the Cyber Resilience Act (CRA), that familiar mark is getting a major cybersecurity upgrade. Think of the new CE mark as a cybersecurity passport…
-
A Practical Guide to CRA CSIRT Reporting Requirements
Under the Cyber Resilience Act, manufacturers face a strict new obligation: if you become aware of a severe security incident or an actively exploited vulnerability in your products, you must notify your designated national Computer Security Incident Response Team (CSIRT) and the EU Agency for Cybersecurity (ENISA) within 24 hours. This initial “early warning” is…
-
CRA Substantial modification definition: EU Compliance Guide for 2026
One of the most critical—and often misunderstood—concepts in the EU’s Cyber Resilience Act (CRA) is the ‘substantial modification’. Getting this wrong can turn what seems like a simple update into a full-blown compliance nightmare, forcing you to treat your product as brand new and start the entire conformity assessment from scratch. Decoding the CRA Substantial…
-
Mastering the CRA Single Reporting Platform for EU Compliance
At its core, the CRA single reporting platform is a centralised EU portal, managed by ENISA, where manufacturers must report actively exploited vulnerabilities and severe security incidents. Think of it as a single, unified “911 dispatch” for cybersecurity, ending the chaos of notifying multiple authorities across different EU member states. What is This New Cybersecurity…
-
Your Guide to the 2026 CRA Annex IV Critical Products List: 8 Key Areas
The EU’s Cyber Resilience Act (CRA) is set to reshape digital product security, introducing strict new rules for manufacturers placing products on the European market. A central part of this legislation is the classification of certain products as ‘critical’ under Annex IV, which subjects them to more rigorous cybersecurity obligations due to their potential impact…
-

Total Virus API: Master the total virus api for CRA Compliance
The VirusTotal API gives you programmatic access to VirusTotal’s enormous, crowdsourced database of threat intelligence. In simple terms, it lets developers and security teams automatically check files, URLs, domains, and IP addresses against the findings of over 70 different security vendors and scanning engines. It’s your direct, automated gateway to one of the world’s largest…
CRA Basics: a practical introduction to the EU Cyber Resilience Act
CRA Basics is a starting point for understanding the EU Cyber Resilience Act (CRA) and what it means for products with digital elements. CRA aims to raise the cybersecurity baseline across the EU by requiring security by design and by default, clearer accountability, and consistent vulnerability handling throughout the product lifecycle.
This page gathers introductory guidance and related posts to help teams quickly understand the fundamentals, identify what is likely in scope, and plan a realistic path toward implementation and ongoing compliance.
What is the CRA in simple terms
The CRA is an EU regulatory framework focused on improving cybersecurity outcomes for products with digital elements placed on the EU market. It encourages organizations to build secure products, ship safer default configurations, and maintain security through updates and vulnerability management over time.
Why CRA Basics matters for product teams
Even a high-level understanding of CRA helps product, engineering, security, and operations teams align early on scope, ownership, documentation needs, and lifecycle responsibilities. Getting the basics right reduces late-stage rework and helps prevent compliance efforts from turning into reactive fire drills.
Key concepts in CRA Basics
These concepts appear repeatedly when translating CRA into engineering and operational practices.
Products with digital elements
CRA is centered on products that include software or digital connectivity. This can include software applications, embedded software, connected devices, and other digital components that may introduce cybersecurity risk.
Security by design
Security by design means planning and implementing cybersecurity controls from the earliest stages of product development, rather than adding them later. It typically includes threat modeling, secure architecture decisions, and preventive engineering controls.
Security by default
Security by default means products should be delivered with secure settings out of the box. Risky defaults such as weak credentials or unnecessary exposed services should be avoided unless there is a controlled and justified need.
Vulnerability handling over the lifecycle
CRA places emphasis on having a structured process to receive vulnerability reports, assess severity and impact, deliver fixes, and communicate updates. Maintaining products through security updates is central to CRA outcomes.
CRA Basics: what to do first
A lightweight starting plan helps you move from awareness to action without creating unnecessary overhead.
Step 1: identify likely scope
- Create a simple inventory of products and versions shipped to the EU market
- Document key components and critical dependencies
- Note major customer deployment models and default configurations
Step 2: assign ownership and roles
- Name a single internal owner for CRA coordination
- Define responsibilities across product, engineering, security, legal, and support
- Establish escalation paths for high-severity vulnerabilities
Step 3: establish foundational controls
- Adopt secure coding and review practices
- Integrate security testing into CI/CD (static, dependency, and where relevant dynamic testing)
- Define a vulnerability intake and triage process with internal SLAs
- Set a security update and supported-version policy
Step 4: start collecting baseline evidence
- Architecture overview and trust boundaries
- Threat model and risk assessment notes
- Security test outputs and remediation tracking
- Documented vulnerability management workflow and communications approach
Related posts and resources for CRA Basics
This section is intended to host beginner-friendly posts that explain CRA concepts and show practical first steps.
Understanding CRA
CRA Basics explained: scope, goals, and who it impacts
An overview of CRA terminology and how to determine whether your products and teams are likely in scope.
Getting started
A CRA Basics checklist for teams: first 30 days
A practical plan for building a product inventory, assigning ownership, and implementing foundational controls quickly.
Engineering foundations
Security by design in practice: the CRA Basics approach
How to integrate threat modeling, secure defaults, and testing into normal delivery workflows.
Vulnerability handling
Vulnerability management for beginners: a CRA Basics playbook
How to set up intake channels, triage rules, remediation SLAs, and customer communications without heavy process.
Evidence and documentation
CRA Basics documentation: what to write down and why
The minimum evidence most teams should keep so CRA-related work remains traceable and defensible over time.
Download free CRA Checklist 2025
The definitive CRA checklist for assessing your organization’s readiness for the Cyber Resilience Act.
By submitting this form, you accept our Terms and acknowledge that Regulus will process your data to send the checklist. For more details, see our Privacy Policy.