Why device lifecycle matters?

The Cyber Resilience Act doesn't regulate a moment. It regulates a lifetime.

That means we're not done once product is built, secured and shipped. By seliing device with digital elements we sell a relationship that should be maintained for years. For the whole lifespan of the device as a producer we have to take care about security of our product.

As a world-old saying states: "divide and conquer" IoT world divided device lifecycle into stages. That helped us build our open-source platform - open things which takes care for each lifecycle phase.

Let's walk the circle. Two pairs of one-time transitions wrap a long operational middle and inside that middle runs a loop that never stops. At each stop: what it is, what the CRA expects, and what you actually need in place.

1. Provision - the device gets an identity

What happens: The device is born. On the manufacturing line, before it ever touches a network, it gets a unique identity, a root of trust, and the keys it will use for the rest of its life. Think of provisioning as issuing a passport.

Every device gets its own identity, credentials, and trust anchors. From that moment on, everything else depends on them.

What the CRA expects No universal default passwords. A secure-by-default state out of the box. A device that can prove it's genuine - not a clone and not a counterfeit.

What you need:

• A unique per-device identity - not a shared key burned into every unit. One compromised device must not compromise the fleet.
• A root of trust - secure boot, so the device only runs firmware you signed.‍
• Keys provisioned safely - injected at manufacturing, stored in hardware where you can (secure element, TPM, TrustZone), never shipped in plaintext.

Get this wrong and nothing downstream is trustworthy. If identity is shared or forgeable, your signed updates, your encrypted telemetry, your access control all of it rests on sand.

How we address that: our platform comes out of the box with OpenBao issues per-device identities. Each device enrolls with its own certificate, backed by a root of trust you control - not a vendor's cloud you rent. You already have something? Not a problem, we designed it so that this part is swappable.

2. Commission - the device is brought into service

What happens: The device is installed, configured, and connected to the environment where it will operate. This is the first moment the device has to prove who it is and verify who it's talking to. The first connection is often the most vulnerable moment in a device's life: if an attacker can impersonate the device or your backend before trust is established everything that follows becomes questionable.

Authentication needs to happen before the device starts doing useful work.

What the CRA expects: Protection of the device's connection from the first packet. Authentication before access. A secure configuration state on delivery.

What you need:

• ‍Certificate-based enrollment -the device authenticates with the identity from phase 1, and your backend authenticates back. Mutual TLS, not a shared API token.‍
• No default passwords, ever - commissioning must force a unique credential or rely on certificates entirely.‍
• Secure-by-default configuration - unused ports closed, debug interfaces disabled, least privilege from the first connection.

Don't treat commissioning as a convenience step. It's the moment an attacker would most like to insert themselves into the trust relationship. Once that happens, every subsequent communication becomes suspect.

How we address that: commissioning in open things is certificate-based with mutual TLS, and certificates rotate automatically, so identities don't quietly expire or live forever, which is its own risk.

3. Operate - work, update, monitor, respond

Operate isn't a phase you pass through; it's a state the device lives in for years. And inside it the same cycle runs over and over: you monitor the fleet, you respond when something is wrong, you update to close the gap and then back to monitoring. The four transitions around it happen once each. This loop happens forever and it's where the CRA's living obligations actually sit. Miss it and a device that shipped secure quietly drifts out of compliance.

3.1. Work - the device does its job

What happens: Years of telemetry flowing up, commands flowing down, and the device doing the job it was designed to do.

What the CRA expects: confidentiality and integrity of data in transit and at rest. Access control. Protection against the obvious attacks on availability. And, crucially, logging of security-relevant events so you can detect and investigate.

What you need:

• ‍Encryption in transit - TLS for every channel, no exceptions, no "internal network so it's fine."‍
• Data minimisation - collect what the product needs, not everything you can. The CRA expects it; GDPR doubles down on it.‍
• Access control - who can read telemetry, who can send commands, scoped per role and per tenant.‍
• Audit logging - an append-only record of who did what and when. This is your evidence when something goes wrong, and your early warning when it's about to.

This phase lasts years, so observabilityt helps: a device you can't see is a device you can't defend. Fleet visibility isn't a nice-to-have; it's how you meet the post-market obligations in the loop below (§4.2).

How we address that: open things is designed to be observed. Telemetry ingestion runs over encrypted channels, access is scoped by the tenant/solution ownership model, and the platform is built to be self-hosted your fleet data stays on infrastructure you control, not a third-party cloud you have to add to your risk assessment.

3.2. Update - the update path is the product

What happens: A vulnerability surfaces. A dependency becomes vulnerable. A bug needs fixing. You need to update devices already deployed in the field. Ten years ago, firmware updates were considered a feature. Under the CRA, they're part of the product. Once a vulnerability becomes public, your ability to patch devices matters more than the quality of the code you shipped on day one.

If you can't update securely, you can't realistically keep the product compliant.

What the CRA expects: Security updates throughout the support period (minimum 5 years, or expected lifetime). A secure update mechanism. The ability to know what's inside every build and whether any of it is now vulnerable. Vulnerability handling is an obligation.

What you need:

• ‍Signed OTA - every update is cryptographically signed, and the device verifies the signature before it installs. Unsigned firmware is rejected. This is non-negotiable; it's the single most exploited gap in IoT.‍
• An SBOM per build - a Software Bill of Materials (CycloneDX or SPDX), generated on every release. You can't patch what you don't know you're shipping.‍
• Continuous vulnerability monitoring - scan that SBOM against CVE feeds (Trivy, Grype, OSV) so a new CVE in a dependency raises a flag against every firmware line that contains it.‍
• Rollback protection - an attacker must not be able to force a device back onto a known-vulnerable version.

A product you can't securely update is a product you can't legally keep on the market once a vulnerability is known. The update path is part of the product.

How we address that: signed firmware updates and SBOM-per-firmware are built in, and the `sbom-monitoring` module watches your bills of materials against vulnerability feeds, so "which devices are affected by this new CVE?" is a query, not a fire drill.

3.3. Monitor & Respond - the device gets watched

What happens: Something goes wrong in the field: an exploit, an anomaly, an incident. The clock starts the moment you know.

What the CRA expects: Post-market surveillance across the support period. And hard reporting deadlines once you become aware of an **actively exploited vulnerability or a severe incident** (these obligations start September 2026, ahead of full CRA application):

Both go to your CSIRT and ENISA through the single reporting platform.

What you need:

• ‍Fleet-wide visibility - version distribution, health, anomalies, all in one place. You can't report on what you can't see.‍
• The audit trail from phase 3 - your evidence for what happened and when.‍
• A vulnerability handling process - receive, triage, fix, communicate. Plus a public coordinated vulnerability disclosure policy (a `security.txt`, a contact, a safe-harbour statement) so researchers can reach you before attackers do.‍
• A reporting runbook - who declares the incident, who notifies, against which deadline. Rehearsed, not improvised at 2am.

24 hours is not enough time to build a process. The reporting machinery has to exist before the incident, or the deadline owns you.

How we address that: the platform ships with a coordinated vulnerability disclosure policy and CVD channels (it satisfies its own CRA disclosure obligation), and fleet visibility plus per-firmware SBOMs give you the raw material for the "which devices, which version, since when" answer the regulator wants. The regulatory reporting is still yours to file. The platform gives you the evidence to file it fast.

4. Decommission - the device leaves service

What happens: End of operational life. The device is pulled from the field - replaced, sold on, or scrapped. It stops doing its job. This is the phase nobody plans for, and the one that leaks data and credentials for years.

What the CRA expects: Secure handling at end of life, so the ability to securely remove user data from the device. And a clear, declared **support period** so customers know when the security updates and your obligation end.

What you need:

• ‍Secure data deletion on the device - wipe user data and secrets, factory-reset to a known clean state before the unit leaves your control.‍
• A graceful exit from operation - stop trusting its telemetry, stop sending it commands.‍
• A declared, published support period - and a plan for what happens when it ends. End of support is a decision, not a thing that happens by neglect.

How we address that: the platform comes with mechanics of detaching from its context and removing data.

5.  Deprovision - the device loses its identity

What happens: The backend counterpart of phase 1. Once the device is out of service, you revoke its identity and erase it from your systems. Provision gave it a life in your fleet; deprovision ends it cleanly.

What the CRA expects: That a removed device cannot rejoin your fleet, and that personal/user data is deleted when no longer needed. At the same time, your technical file and security records stay retained (10 years / support period) - deleting user data is not the same as deleting evidence.

What you need:

• ‍Identity revocation - pull the device's certificate from the PKI / revocation list so a scrapped or stolen unit can't authenticate again. Per-device identity makes this surgical; a shared key means re-keying the whole fleet.‍
• Backend data cleanup - delete the device's records, telemetry, and credentials from your management plane on a defined retention schedule.‍
• Keep the compliance trail - retain the technical documentation and incident history even after the device and its personal data are gone.

A retired device that keeps a valid certificate is a backdoor with a battery. Revocation is the difference between "deprovisioned" and "still trusted, just forgotten."

How we address that: because identity is per-device and certificate-based, revoking one unit is a clean operation against the PKI. No shared key to rotate across the fleet, no orphaned credentials left trusted, and fleet records are scoped per tenant so cleanup is contained.

The circle closes and never really stops

The lifecycle nests in mirror pairs around a working core:‍

• ‍Provision - Deprovision - identity created, identity erased.‍
• Commission - Decommission - brought into service, taken out of service.‍
• Operate  + the operational loop - the core, where the device spends its years running and updating, again and again.

The transitions at the edges happen once each.

The identity you provision (1) is exactly what lets you deprovision cleanly (6). The audit log you design while operating (3) is your evidence when you respond (4.2). The SBOM you generate on every update (4.1) is what makes the next CVE searchable instead of catastrophic.

That's the real insight the CRA encodes: security isn't a phase, it's the loop. A device that's secure at birth but unmaintainable is non-compliant.

What you can start today

You don't need every phase perfect on day one. You need them *designed in*. Start here:

Quick wins (days)

• Publish a `security.txt` and a disclosure policy
• Generate an SBOM on every build
• Kill default passwords - force a unique credential or certificate at commissioning

Medium effort (weeks)

• Stand up signed OTA and verify signatures on-device
• Turn on TLS everywhere and audit logging
• Declare and publish your support period

Larger effort (months)

• Per-device identity with a real root of trust
• Certificate-based enrollment with mTLS
• Continuous SBOM-vs-CVE monitoring across the fleet

Or start with a platform that already does the heavy lifting. OpenThings is our open-source, self-hostable IoT platform built around exactly this lifecycle. Per-device identity, certificate rotation, signed firmware, SBOM-per-build, vulnerability monitoring, and a coordinated disclosure policy. CRA-ready, AGPL-3.0, no cloud vendor lock-in.

The bottom line

The CRA doesn't ask "is your device secure?" It asks "is your device secure for its whole life and can you prove it at every phase?"

Provision an identity. Commission it with certificates. Operate encrypted and observed and inside that, keep the loop turning: monitor, respond, update, without pause. Decommission cleanly. Deprovision so nothing's left trusted. Four transitions at the edges, one loop in the middle, one continuous obligation.

Build for the circle, not the launch.

Want to see the lifecycle running? OpenThings will be open source stay tuned but now you can take a look and if you'd rather we help you map your product onto it get in touch.

‍