Sign the firmware
Create a signed firmware artifact that devices can verify before accepting or running the update.
Security updates and automatic-update readiness
CRA security-update readiness is more than file delivery
OEMs need to show not only that security updates can be delivered, but that firmware is signed, devices are eligible, rollout behaviour is governed, retry and rollback paths are defined, device state is tracked, and evidence is retained.
OTA delivery answers how an update reaches a device. CRA readiness also requires showing which firmware was trusted, which devices were eligible, what policy applied, what happened during rollout, and what evidence remains.
QuarkLink supports secure update workflows across device and control plane: signing, secure delivery, eligibility checks, rollout rules, retry or rollback handling, lifecycle state, and retained evidence.
A security update as a device-trust decision
SignSet policyCheck eligibilityRoll outPause / rollback / quarantineRetain evidence
A security update should be treated as a device-trust decision: what is signed, which devices are eligible, what policy applies, what happened during rollout, and which records remain. The update file is only one part of the decision; the workflow also needs identity, certificate state, lifecycle state, rollout policy, and evidence.
The controls behind a trusted security update
Define the release scope
Specify which product, device family, version, or device cohort is eligible for the security update.
Apply rollout rules
Control staged rollout, retry thresholds, pause conditions, rollback paths, and approval gates.
Verify device eligibility
Check identity, certificate state, lifecycle state, firmware version, and policy before rollout.
Track update state
Record pending, eligible, delivered, installed, failed, paused, or rolled-back states where the device architecture reports them.
Retain evidence
Keep the signing record, eligibility decision, rollout history, device update state, and audit summary.
From CRA update concern to retained evidence
| CRA concern | Workflow control | Evidence retained |
|---|---|---|
| Firmware authenticity | Sign firmware before release and bind it to a governed update workflow. | Signed firmware record, release ID, eligibility decision. |
| Device eligibility | Check device identity, certificate state, lifecycle state, firmware version, and policy. | Eligible device cohort, policy decision, rejected or paused devices. |
| Automatic-update readiness | Configure rollout rules, staged deployment, pause conditions, retry or rollback behaviour, and approval gates. | Update policy, rollout state, pause / retry / rollback decisions. |
| Vulnerability handling | Identify affected devices, govern the update workflow, and quarantine or revoke trust where needed. | Affected cohort, update campaign, quarantine or revocation history. |
| Data integrity | Verify signed updates and reject unsigned or tampered firmware where device architecture supports it. | Verification result, rejection event, firmware-integrity status. |
| Support period | Retain update state, lifecycle state, and audit records throughout the support period. | Update status, lifecycle history, audit summary. |
Signed firmware update workflow
Track how a signed firmware release moves from artifact signing through device eligibility, rollout policy, verification, fallback handling, and evidence retention.
Firmware update workflow
2.4.1 security release
Workflow gates
Signed artifact
controller-fw-2.4.1-security.bin Signature and release record retained.Eligibility checked
8,203 devices approved Identity, certificate, firmware version, and lifecycle state checked.Rollout configured
Staged deployment Pause condition, retry threshold, approval gate, and rollback path set.Verification tracked
Signature verification ready Unsigned or tampered firmware rejected where supported.Fallback path set
Retry, rollback, or quarantine Failed or risky devices can be isolated from rollout.Evidence retention enabled
Audit summary ready Signing, eligibility, rollout, status, and lifecycle events retained.Representative QuarkLink app screen. Example data shown.
QuarkLink support and OEM responsibility
QuarkLink supports the secure update workflow; OEMs define the product-specific policy, user experience, validation, and compliance programme around it.
QuarkLink supports
Signing, secure delivery, eligibility checks, rollout rules, retry/rollback handling, lifecycle state tracking, and retained evidence.
OEM responsibility
Product-specific update policy, user/operator experience, release governance, final-product validation, vulnerability remediation quality, customer notices, and overall CRA compliance.
Together, they support
A controlled update workflow with trusted firmware, eligible devices, configured rollout behaviour, recoverable update handling, and evidence for technical documentation and audit preparation.
Build update evidence into the lifecycle
Treat every security update as a trust decision: which devices are eligible, what policy applies, what changed, what failed, and which evidence remains.