Market access creates urgency
CRA makes connected-product security a board-level and product-launch issue. OEMs need to preserve EU market access with controls they can operate.
CRA readiness for connected-product OEMs
Turn CRA market-access pressure into device-trust controls
CRA turns connected-product security into a compliance and EU market-access issue. OEMs need secure-by-design products, secure defaults, security-update readiness, support-period processes, vulnerability handling, and evidence that their controls are real.
Why this matters now
Manufacturer accountability needs workflows
Secure-by-design, secure-default, update, support-period, and vulnerability-handling asks need repeatable device-level decisions.
Evidence burden changes the conversation
Product-security and compliance teams need records for what was provisioned, updated, revoked, quarantined, or decommissioned.
CRA timeline at a glance
The Cyber Resilience Act entered into force on 10 December 2024. Reporting obligations start on 11 September 2026, and the main obligations apply from 11 December 2027. European Commission summary and Regulation (EU) 2024/2847.
CRA ask to device-trust control
| CRA buyer ask | Device-trust control | QuarkLink proof |
|---|---|---|
| Secure by design | Device identity, secure provisioning, credentials, certificates, update trust, and lifecycle evidence are designed into the product. | Policy, provisioning record, certificate detail, update rule, and lifecycle history. |
| Secure by default | Devices start from a trusted initial state with per-device credentials, controlled onboarding, and firmware integrity support. | First-connection record, certificate issue event, onboarding target, and firmware-integrity status where supported. |
| Security updates / automatic-update readiness | Firmware is signed, updates are authorized, eligible devices are identified, and rollout state is recorded. | Signed firmware record, update authorization, status history, retry or rollback decision. |
| Protection from unauthorised access | Genuine device identity, certificates, mutual authentication, and trust policy control which devices can connect. | Device identity detail, certificate state, onboarding target, and access history. |
| Data integrity | Firmware, commands, configuration, and device communications are protected from unauthorised modification. | Signed firmware record, firmware-integrity status, update authorization, and audit events. |
| Support period | Trust remains manageable through certificate renewal, update support, revocation, quarantine, and decommissioning. | Certificate renewal history, lifecycle state changes, revocation and decommission records. |
| Vulnerability handling | Affected devices can be found, updated, quarantined, revoked, or decommissioned as the response requires. | Device cohort, update campaign, quarantine state, revocation event, audit log. |
| Technical documentation / evidence | Device-trust workflows create records that support product security files and customer assurance. | Evidence summary covering provisioning, certificates, updates, revocation, and lifecycle state. |
CRA readiness path
Identify exposed productsDefine device trust modelProvision identitiesAuthorize updatesOperate lifecycle stateRetain evidence
Product and architecture decisions
- Identify which connected products, variants, and support periods are CRA-exposed.
- Define the device identity model, key boundary, trust policy, and firmware-integrity controls.
- Decide how device trust connects to product risk assessment and secure-by-design architecture.
Operational workflow decisions
- Plan provisioning for manufacturing, first boot, or controlled first connection.
- Define certificate issuance, renewal, rotation, expiry, and revocation workflows.
- Define signed update authorization, device eligibility, rollout state, quarantine, and decommissioning workflows.
Evidence and boundary decisions
- Capture lifecycle states such as active, revoked, quarantined, transferred, and decommissioned.
- Decide which records support technical documentation, customer assurance, and support-period review.
- Separate device-trust evidence from SBOM, vulnerability disclosure, incident reporting, CE marking, and conformity assessment.
Product proof: CRA device-trust evidence summary
This proof panel shows the kind of device-trust evidence an OEM can use to support technical documentation, customer assurance, and support-period review.
Connected-product device family
Per-device credential and certificate record created.
Issuance, renewal, expiry, and revocation history available.
Firmware signing, eligibility, rollout state, and status retained.
Active, quarantined, revoked, transferred, or decommissioned.
Risky devices can be quarantined, revoked, or decommissioned.
Lifecycle record available for review and assurance discussions.
Where device trust helps, and where broader work remains
QuarkLink connects the Device SDK, QuarkLink Cloud, and CLI / API automation so OEMs and their partners can operate the device-trust workflows behind CRA readiness.
QuarkLink helps implement and evidence device-trust controls. It does not replace SBOM, vulnerability disclosure, incident reporting, conformity assessment, CE marking, full product risk assessment, mobile or cloud application security, or the full technical documentation package.
Start your CRA readiness path
Use QuarkLink Ignite to evaluate the first device workflow, compare plans for rollout, or talk to us about production and partner delivery.