By José Francisco Agulló (ERNI Spain)
As digital products evolve into complex ecosystems – combining cloud services, embedded controllers, mobile applications and enterprise integrations – their cybersecurity requirements grow exponentially. With the EU Cyber Resilience Act and stricter MDR, ISO 14971 and IEC 81001-5-1 rules, manufacturers must prove their products are secure throughout their lifecycle.
Recently, our team supported a manufacturer preparing a next-generation connected system involving cloud components, embedded devices, wireless interfaces and third-party integrations. While the specifics remain confidential, the challenges are representative of what many organisations face today. This article outlines how we structured the advisory programme, the reasoning behind our methodology, and the strategic lessons learned – showing what ‘secure by design’ really looks like when applied to real products.
Why lifecycle cybersecurity is no longer optional
Regulations like the Cyber Resilience Act fundamentally shift cybersecurity from a ‘best effort’ approach to a legal obligation. Manufacturers must now:
- Identify threats from design phase onward
- Provide secure defaults and update
mechanisms - Maintain an SBOM
- Assess exploitability pre-market
- Implement vulnerability management processes
- Document security controls in a technical file
- Support post-market monitoring through out the entire lifecycle
For many companies, these are completely new disciplines. Our use case centred around creating a structured, defensible and traceable security programme that turns these obligations into clear engineering practices.
Building security from first principles: Threat modelling and risk analysis
The engagement began where every secure product should begin: with a deep understanding of the system and its risks.
Our philosophy: You cannot secure what you do not understand. And you cannot understand a system unless you model how data flows through it. We worked with engineering teams to create:
- Level 0 and Level 1 data flow diagrams
- Trust boundaries across cloud, embedded, mobile and enterprise interfaces
- STRIDE-based threat models for each component
- A risk matrix aligned with MDR + CRA Article 10
This stage forces clarity on:
- Where sensitive data lives
- Which modules introduce exploitable attack surfaces
- How components depend on each other
- Where security controls must be enforced
- What can go wrong, and how severely
Most importantly, it establishes the security intent, which auditors will later expect to see reflected in architecture and documentation.
Designing a secure architecture that supports the regulation
The second phase focused on defining a CRA-aligned secure architecture. Instead of adding security layers after development, the objective was to embed them into the foundation of the system. Our approach followed four core principles:
1. Zero Trust for connected products
Every interface – Bluetooth, USB, cloud API, workstation – must assume compromise by default.
2. Secure communication everywhere
We designed encryption strategies for:
- Device ↔ cloud
- Device ↔ local workstation
- Device ↔ mobile
- Firmware update channels
- Enterprise system integrations
3. Identity drives authorisation
Role-based access control and proper IAM design ensure that only the right entities can perform sensitive operations – critical for compliance under CRA Annex II.
4. Architecture must be explainable to auditors
This is key: a secure system that cannot be justified during an audit is not compliant. The result was a secure architecture specification, integrating access control, encryption, update policies, secure defaults and supply chain considerations.
5. Embedding security into the development lifecycle
One of the biggest gaps for manufacturers is that security is often not integrated into the SDLC. CRA and IEC81001-5-1 demand:
- Secure coding requirements
- Reproducible development processes
- Vulnerability handling workflows
- Traceable evidence of testing and review
- SBOM generation and maintenance
Our role was to help the development team operationalise these concepts. We introduced:
- Security requirements per module
- SAST and DAST tools
- Manual secure code reviews
- Coding guidelines aligned with Annex II
- SBOM strategy and tooling
- Training for developers on threat patterns and mitigations
Philosophy: Security must become part of everyday engineering – not a ‘compliance activity’.
Validating the security posture through real testing
No matter how strong the design, a security programme is incomplete without hands-on validation. We performed:
- Penetration testing across cloud, device and workstation interfaces
- Fuzzing of USB and Bluetooth channels
- Robustness testing with malformed inputs
- Validation of logs, audit trails and times tamp integrity
- Review of update mechanisms and rollback paths
This phase serves two purposes:
- Demonstrate the effectiveness of the implemented security controls
- Generate the evidence required for CRA technical documentation
Testing uncovered several areas for improvement, but also confirmed that core architecture decisions were sound.
Producing the technical file for CRA and MDR
Regulators expect not just compliance, but demonstrable, traceable, auditable compliance. We helped the client assemble:
- Threat models
- Vulnerability assessments
- Security requirements
- SBOM documentation
- Update policy
- Risk assessment per Annex II
- Incident response plan
- Architecture dossier
- Validation and test reports
The final output was a complete CRA-aligned technical file, ready for notified bodies and pre-market evaluation.
Key insights from this case
This engagement highlights lessons valuable for any manufacturer developing connected products:
1. Cybersecurity must start before the first line of code
Threat modelling saved months of rework and prevented architectural mistakes.
2. CRA is not just a regulation; it is a lifecycle mindset
Compliance is achieved through continuous processes, not isolated deliverables.
3. Documentation is as important as technical controls
Auditors must understand why decisions were made, not only what was implemented.
4. Secure development is a cultural shift
Teams must internalise principles like least privilege, defence-in-depth and secure defaults.
5. Testing needs to reflect real attacker behaviour
Fuzzing, malformed input testing and endpoint abuse scenarios reveal issues traditional testing misses.
6. A structured programme dramatically reduces regulatory risk
By aligning architecture, development, testing and documentation with the same framework, compliance becomes manageable – and predictable.
Conclusion: A practical path to secure, compliant and resilient products
The Cyber Resilience Act marks a turning point. Manufacturers of connected products must now
demonstrate security throughout the entire lifecycle – design, development, validation and post-mar
ket. This use case illustrates how a structured advisory programme can guide organisations from un
certainty to readiness:
- Clear threat understanding
- Secure architecture
- Secure coding practices
- Testing that reflects real-world threats
- Documentation that withstands regulatory scrutiny
- Documentation that withstands regulatory scrutiny
By treating cybersecurity as an engineering discipline rather than a checkbox exercise, companies
can build products that are not only innovative but also trustworthy, resilient and compliant with the
new European standards.
