This is Part 2 of the CRA compliance guide. If you haven’t read Part 1: Understanding Requirements and Planning Your Journey, we recommend starting there to understand the regulatory foundation and compliance strategy before diving into technical implementation.
In Part 1, we explored the CRA regulatory landscape, legal requirements, and strategic planning approaches. Now comes the crucial question: How do you actually build products and systems that meet these requirements?
The gap between understanding CRA obligations and implementing compliant systems is where most organizations struggle. You know you need secure-by-design products and vulnerability management processes—but what does that actually look like in practice?
What You’ll Learn in This Series
In this second part, you’ll discover:
-
A comprehensive four-layer reference architecture that addresses every major CRA requirement
-
Concrete implementation patterns with real-world tooling recommendations
-
How leading manufacturers transform compliance challenges into competitive advantages
-
Practical next steps for your technical teams, regardless of your current security maturity
Let’s build the technical foundation that makes CRA compliance systematic rather than overwhelming.
Building a Reference Architecture for CRA Compliant Connected Products
Architecture Overview
The architecture we’re building follows a logical progression: secure what you build → respond when threats emerge → deploy fixes to the field → protect devices in operation. Each layer builds on the previous one, creating a comprehensive defense system that transforms vulnerability management from reactive scrambling into systematic protection.
This addresses the complete security lifecycle, from the moment you write code to the day you decommission a device.
Layer 1: Secure What You Build
The foundation of CRA compliance starts with secure development practices that catch vulnerabilities before they reach customers. Think of this as your first line of defense: preventing known issues from ever making it into production.
The Development Security Pipeline
If you’re already developing software, you’re likely familiar with CI (Continuous Integration) pipelines—the automated systems that run tests, build software, and validate code quality every time developers commit changes. These pipelines are already the backbone of modern software development, ensuring that new code doesn’t break existing functionality.
Core Security Components
For CRA compliance, we need to extend this familiar concept by adding security as another automated check. Every code change triggers automated security checks—no exceptions. Your CI pipeline becomes a security gatekeeper that prevents vulnerable code from advancing. Key components include:
-
Automated security scanners like SonarQube for static analysis and Snyk for dependency scanning that catch common issues like unvalidated inputs, hardcoded credentials, and insecure configurations
-
SBOM generation that creates a detailed inventory of every component, library, and dependency in your software
-
Reproducible builds that ensure the same source code always produces identical binaries
Managing Open Source Dependencies
A word on Open Source: The CRA has significant implications for open source software. Bottom line: You’re now accountable for the security of all open source components in your products. If upstream maintainers won’t take CRA responsibility, you must document, track, and remediate vulnerabilities for these dependencies yourself.
Beyond basic automation, you also need threat modeling during design phases, secure coding standards (MISRA C, CERT guidelines, or memory-safe languages), and protection of your build environment against supply chain attacks. For comprehensive security practices, consider implementing OWASP SAMM (Software Assurance Maturity Model) to systematically improve your security posture.
Artifact Repositories for Vulnerability Tracking
Your artifact repository becomes crucial for CRA compliance: When every software artifact includes its complete SBOM, your repository becomes a searchable database of components across your entire product line—enabling precise vulnerability impact assessment.
Why is this important?
A dependency that’s secure today could have a critical vulnerability tomorrow. In 2024, over 100 new CVEs were published daily, and this year, we are at over 130 new CVEs that are published daily.
With an SBOM, when a new CVE affects OpenSSL 3.1.2, you instantly know which products contain that version and need patching. This capability transforms vulnerability response from “we think these products might be affected” to “these exact builds are vulnerable.”
Essential Vulnerability Tracking Processes
-
Continuously scan all components in your artifact repository against CVE databases
-
Risk-assess vulnerabilities in your product context (not all CVEs are exploitable in every system)
-
Automate notification workflows so your security team learns about relevant threats immediately
Implementation Options
There is a lot of tooling available to automate vulnerability monitoring. Platforms like GitHub provide integrated solutions with CI/CD pipelines, security scanning, and dependency management through tools like Dependabot. For IoT-specific needs, specialized build systems like Rugix Bakery can generate both firmware images and SBOMs in a single build step, streamlining the compliance documentation process.
CRA Compliance Impact: This development security layer addresses P-2a (no known exploitable vulnerabilities at release), P-2j (limit attack surfaces), VH-1 (maintain SBOM & document vulnerabilities), VH-2 (remediate vulnerabilities promptly), and VH-3 (perform regular security testing & reviews). More importantly, it creates the audit trail and infrastructure needed for all subsequent security operations.
Layer 2: Respond When Threats Emerge
Your secure development practices caught most vulnerabilities—but not all. New threats emerge daily, and some will slip through your defenses. This layer is about building systems that respond quickly and transparently when vulnerabilities surface in deployed products.
Building a Coordinated Vulnerability Disclosure (CVD) Program
The CRA’s vulnerability handling requirements demand systematic processes for identifying, addressing, and disclosing security issues. Manufacturers must maintain SBOMs, remediate vulnerabilities “without delay”, and implement coordinated vulnerability disclosure policies that encourage responsible reporting.
The Crisis Communication
What many technical teams underestimate: vulnerability disclosure isn’t just about technology—it’s crisis communication. When a critical vulnerability affects thousands of deployed devices, you must coordinate multiple communication streams simultaneously while maintaining composure under pressure.
Following frameworks like FIRST’s CVD Guide ensures your program meets industry standards.
Disclosure Portal
Your vulnerability disclosure portal serves as the central communication channel towards your customers. Services like the Cert@VDE disclosure platform provide centralized infrastructure for coordinated vulnerability disclosure, making it easy for your customers to stay informed.
Layer 3: Deploy Fixes to the Field
Now comes the moment of truth: you’ve found a vulnerability in deployed devices and need to fix it. For offline devices, you can publish updates on your website and hope customers install them. For connected products, the CRA requires automatic security updates as the default option.
This is where connected devices become fundamentally different from traditional software products. You’re not just managing code—you’re managing a distributed fleet of hardware that could be anywhere in the world, potentially with limited network connectivity, power constraints, and no direct human oversight.
Device Identity Management
Before you can securely update devices, you need to ensure you’re communicating with the right devices. The industry best practice is X.509 client certificate authentication, which enables unforgeable device identities, mutual authentication, and certificate lifecycle management across your fleet.
Secure OTA Updates
Successful over-the-air (OTA) updates require solving multiple technical problems simultaneously:
-
Cryptographic verification with certificate pinning ensures only authorized updates install
-
Atomic deployments using A/B partition systems prevent devices from ending up in broken states
-
Rollback mechanisms automatically recover from failed updates
-
Bandwidth optimization handles poor network conditions
-
Fleet orchestration manages updates across thousands of devices without overwhelming your infrastructure
The IoT Platform
For connected products, you’ll need a device management system that can handle secure over-the-air updates across your entire fleet. In practice, this means deploying an IoT platform that becomes the central nervous system for your entire security operation. It needs to handle device identity management, secure communication channels, update orchestration, and security event monitoring—all while maintaining visibility into software versions across your entire fleet.
Fleet-Wide Visibility and SIEM Integration
This fleet-wide visibility becomes crucial for vulnerability management: when a new CVE is published, you can instantly identify which devices need patching and prioritize updates accordingly, rather than waiting for customers to manually check and update devices. Also, your CISO will likely be keen on integrating security events from your devices with your company’s SIEM (Security Information and Event Management) system to provide unified security monitoring. This integration allows security teams to correlate device events with broader infrastructure threats while maintaining the comprehensive audit trails required for CRA compliance reporting and incident response.
Implementation Options
When selecting an IoT platform, look for comprehensive device management capabilities including integrated certificate lifecycle management (provisioning, rotation, revocation). Platforms like Cumulocity IoT offer these features along with certificate management capabilities. Consider combining your platform with lightweight device-side frameworks like thin-edge.io (under 1MB footprint) and specialized update systems like Rugix Ctrl for atomic updates and automatic rollbacks. If your organization requires additional enterprise-grade PKI capabilities, specialized certificate management providers like Device Authority or Keyfactor can extend your platform’s capabilities.
Layer 4: Protect Devices in Operation
Even perfect updates mean nothing if attackers can tamper with your devices directly. The final layer addresses the hardest problem: securing devices that could be physically compromised. Software updates are meaningless if attackers can modify your device’s firmware, extract cryptographic keys, or tamper with sensor data. The CRA requires comprehensive device integrity protection throughout the entire lifecycle.
Here’s the key consideration: While modern integrity protection mechanisms benefit from hardware-level support, the CRA takes a risk-based approach. This means you can often achieve compliance with existing devices through software-based security measures, and operational controls—especially if your risk assessment shows these approaches effectively address your product’s threat landscape.
However, for future product generations, you should still plan for hardware-based security early in your design process. The hardware decisions you make today determine what security capabilities you’ll have available in 3-5 years, and hardware-backed security provides the strongest foundation for comprehensive device protection.
The Hardware Security Roadmap
Most manufacturers handle this with a two-phase approach:
Phase 1: Software-Based Protection
While waiting for hardware updates, you can implement significant security improvements in software. Certificate-based authentication eliminates hardcoded passwords, cryptographic verification prevents unauthorized updates, and secure communication protocols protect data in transit.
Phase 2: Hardware-Backed Security
Next-generation designs incorporate Hardware Security Modules (HSMs) or secure elements for tamper-resistant key storage, secure boot processes, and hardware-backed attestation. These hardware features provide the foundation for comprehensive integrity protection.
Software Security Features
Regardless of hardware capabilities, you need software that bridges current limitations with future security features. This includes:
-
Secure by default configuration — eliminates default passwords and unnecessary services
-
Unforgeable device identities — certificate-based authentication prevents impersonation attacks
-
Secure communication channels — protect all device-to-cloud interactions with encryption
-
Atomic update deployment — updates either succeed completely or roll back automatically
-
Integrity monitoring — detects unauthorized changes and reports corruption
-
Tamper-resistant logging — preserves security events even during attacks
-
Data minimization and lifecycle management — from secure provisioning to factory reset
Implementation Options
The most effective approach combines lightweight device frameworks (like thin-edge.io for connectivity) with specialized update systems (like Rugix Ctrl for atomic deployments). This architecture works with both current hardware and next-generation security chips, providing flexibility as your security capabilities evolve.
Coming Soon: Our comprehensive technical whitepaper will provide detailed implementation guidance for this entire reference architecture, including step-by-step deployment instructions, configuration examples, and compliance mapping against CRA requirements.
The Complete Security Lifecycle in Action
When you integrate all four layers, you create a comprehensive security lifecycle that transforms how you handle threats.
Discovery & Assessment (Layer 1)
Your continuous monitoring detects a new CVE affecting OpenSSL in your artifact repository. Automated SBOM scanning immediately identifies which product versions contain the vulnerable component and assesses exploitability in your specific context.
Coordinated Response (Layer 2)
Your vulnerability disclosure process kicks in, coordinating internal teams, notifying customers, and preparing public disclosures while maintaining the security researcher relationships that help you stay ahead of threats.
Rapid Deployment (Layer 3)
Your IoT platform identifies exactly which devices in the field need patches. Instead of hoping customers manually update, you push cryptographically verified fixes directly to affected devices with automatic rollback protection.
Device Protection (Layer 4)
Throughout the entire process, your devices maintain integrity protection and security event logging, providing the audit trail needed for compliance while protecting against tampering during the update process.
The Architecture Advantage
This integrated approach transforms vulnerability management from a reactive scramble into a systematic response capability. Organizations with this architecture can deploy patches across thousands of devices within hours instead of weeks, while maintaining complete audit trails for regulatory compliance.
More importantly, you’re building security infrastructure that grows stronger over time. Each vulnerability you handle improves your processes, expands your threat intelligence, and strengthens your relationships with the security research community.
How Cumulocity Can Support Your CRA Compliance Journey
This comprehensive architecture might seem overwhelming—and it represents a significant undertaking.
What we observe
Organizations struggle most to develop a concrete CRA strategy and establish a clear roadmap for implementation. This is essential to actually start with implementation.
Our Service Package
That’s why we’ve developed the Cyber Resilience Act Readiness Assessment to help your organization understand, review, and prepare for CRA compliance in the context of your connected products.
How does it work? Three focused phases plus stakeholder interviews:
Phase 1 – Discovery Session
Introduction to CRA regulation, review of a functional reference architecture, and co-development of a CRA readiness checklist.
Phase 2 – Gap Analysis Workshop
You present your IoT device fleet and existing capabilities. Together, we clarify CRA requirements in your context, develop a Gap Analysis, prioritize risks, and draft your customized “CRA compliant” architecture.
Phase 3 – Report of Findings
Final Gap Analysis with risk & mitigation recommendations, customized Enterprise Architecture for CRA compliance, and proposed short-, medium-, and long-term action plan.
Plus: Up to Five One-on-One Stakeholder Interviews
Subject matter expert sessions with key stakeholders to ensure comprehensive understanding and alignment.
What you gain
Clarity on your compliance path with expert guidance from Cumulocity, aligned stakeholders, a customized reference architecture, and prioritized action plan.
If you’re interested, let us know!
More Resources
Looking for more CRA resources? Check out Part 1: Understanding Requirements and Planning Your Journey for regulatory foundations and compliance strategy, or stay tuned for our comprehensive technical whitepaper with detailed implementation guidance (releasing soon).
Watch the practical demonstration: See how Microsoft, Cumulocity with thin-edge.io, and Rugix work together to build CRA-compliant devices in this comprehensive video walkthrough.