How should security teams implement secure-by-design cryptographic controls for connected products sold in the EU?

Teams should treat cryptography as a product requirement, not a late-stage control. Build unique device identity at manufacture, encrypt data in transit and at rest, and require signed firmware and software updates before installation. Pair those controls with a product-specific risk assessment and audit evidence so the design can be justified during conformity assessment.

Why This Matters for Security Teams

For connected products sold into the EU, cryptography is no longer just a technical hardening choice. Under the EU Cyber Resilience Act and related conformity expectations, it becomes part of the product’s security claim, supply chain evidence, and update assurance story. Security teams need controls that can be tested, documented, and repeated across manufacturing, deployment, and lifecycle support. That means unique device identity, trusted boot and update paths, and strong key handling are design requirements, not optional extras. NIST SP 800-53 Rev 5 Security and Privacy Controls provides a useful baseline for control intent, while the product evidence must still satisfy the regulatory context.

The practical risk is that weak cryptography fails quietly. Devices ship with shared keys, firmware updates arrive unsigned, certificates expire without recovery paths, or secrets are embedded in build systems and never removed. NHIMG research shows that 79% of organisations have experienced secrets leaks, and 77% of those incidents caused tangible damage, which is a useful warning sign for connected product teams that assume manufacturing controls will hold indefinitely. In practice, many security teams discover cryptographic failure only after a field update, partner integration, or audit exception exposes the gap, rather than through intentional validation before launch.

How It Works in Practice

Secure-by-design cryptography for connected products starts with identity at manufacture. Each device should receive a unique, non-shared identity, with keys generated and protected in hardware where possible. That identity is then used to authenticate the device to update services, backend APIs, and operational tooling. For many product lines, the cleanest pattern is to pair device certificates with a controlled provisioning flow, then rotate credentials on a defined lifecycle rather than leaving them static for the life of the product.

At runtime, the core rule is simple: encrypt data in transit, encrypt sensitive data at rest, and sign every firmware or software image before installation. The signing process should be tied to a release pipeline that preserves provenance, versioning, and revocation records. Current guidance also favours cryptographic agility, because products that live for years will outlast algorithms, certificates, and trust anchors.

• Use unique per-device keys or certificates, never shared fleet credentials.
• Require signed updates, verify signatures before execution, and reject unsigned rollback attempts.
• Protect root and intermediate keys with segregated build and release controls.
• Log key issuance, rotation, revocation, and failed verification events for audit use.
• Document recovery procedures for expired certificates and compromised signing material.

For evidence, teams should map these controls to product risk assessment outputs and conformity artefacts, then retain records that show how cryptographic decisions were made, tested, and approved. The most effective programs align product engineering with security operations and compliance from the start, not at the certification stage. NHIMG’s Ultimate Guide to NHIs — Standards is useful here because it frames identity, rotation, and lifecycle discipline as operational controls rather than abstract policy. These controls tend to break down when legacy devices cannot support modern signature validation or when field updates depend on distributors with inconsistent key management.

Common Variations and Edge Cases

Tighter cryptographic control often increases engineering and supply chain overhead, requiring organisations to balance stronger assurance against device cost, support complexity, and long product lifetimes. That tradeoff is especially visible in low-power or resource-constrained devices, where full certificate stacks, secure elements, or frequent rotations may not fit cleanly.

There is no universal standard for every implementation detail yet, but current guidance suggests a few defensible patterns. If a device cannot support robust at-rest encryption, focus on minimising sensitive local storage and making secret exposure time as short as possible. If offline operation is required, design a bounded trust model that limits what the device can do without revalidation. If third-party manufacturing or update services are involved, the cryptographic supply chain must be treated as part of the product attack surface, not an externality.

This is where The State of Non-Human Identity Security becomes relevant: if identity and secret governance are weak in enterprise systems, they are usually weaker still in product build and provisioning environments. For implementation detail, the NIST SP 800-53 Rev 5 Security and Privacy Controls and the EU Cyber Resilience Act are the references most teams use to anchor policy, testing, and evidence. The hardest edge case is long-lived deployed hardware, where cryptographic decisions made at launch must still be defensible years later after staff, vendors, and algorithms have changed.

Related resources from NHI Mgmt Group

• How should security teams implement secure SDLC controls across modern delivery pipelines?
• How should security teams implement secure design in the software lifecycle?
• How should security teams design AI evaluation platforms to support GDPR residency and access controls in EU environments?
• How should engineering teams implement secure-by-design and secure-by-default controls under the UK Cybersecurity and Resilience Bill?