Identity and provisioning
Who the device is, how its trust was created, and which onboarding target was approved.
Device-trust evidence for technical documentation
Build device-trust evidence as the lifecycle runs
OEMs need evidence that device-trust controls are real and operating: provisioning records, certificate history, signed update workflows, revocation, quarantine, decommissioning, lifecycle state changes, and audit summaries that can support CRA readiness, technical documentation, and customer assurance.
What OEMs need in a device-trust evidence pack
A device-trust evidence pack should make lifecycle controls reviewable: how trust was created, how credentials changed, how updates were governed, and why devices moved through lifecycle states.
Certificates and access
Which credentials were valid, renewed, rotated, expired, or revoked over the support period.
Updates and integrity
Which firmware was signed, which devices were eligible, what rollout rules applied, and what happened during update delivery or installation where known.
Lifecycle decisions
Why devices remained active, were transferred, quarantined, revoked, or decommissioned.
Evidence should be created as the lifecycle runs
ProvisionedCertificate issuedUpdate governedState changedTrust revoked or decommissionedEvidence exported
A useful evidence pack is not created at the end of a project. It grows from the same events that establish identity, issue certificates, govern secure update workflows, change lifecycle state, revoke or constrain trust, and export records for review.
Device-trust evidence export
Review how QuarkLink packages identity, certificate, update, revocation, lifecycle, and audit records into a reviewable evidence export, with coverage status and retained source records.
Device-trust evidence export
Smart Controller Evaluation Fleet
Evidence coverage
- Provisioning records
- Complete
- Certificate lifecycle
- Complete
- Secure update workflow
- Review needed
- Revocation / quarantine
- Complete
- Lifecycle state
- Complete
- Audit summary
- Export ready
Representative QuarkLink app screen. Example data shown.
What each evidence item can — and cannot — prove
| Evidence item | What it proves | What it does not prove | QuarkLink proof point |
|---|---|---|---|
| Provisioning record | A unique device identity, credential, certificate, and onboarding target were created. | Full product risk assessment or source-code security. | Provisioning job, certificate issue event, first connection. |
| Certificate history | Credentials were issued, renewed, expired, rotated, or revoked through a controlled lifecycle. | All application or cloud access-control decisions. | Certificate issuance, renewal, expiry, and revocation history. |
| Update workflow and status | A signed firmware release was checked for eligible devices and rollout state was tracked. | Automatic installation behavior in every customer architecture. | Signed firmware record, update rule, rollout status, retry or rollback event. |
| Revocation / quarantine / decommissioning | Trust can be removed or constrained when devices are compromised, retired, or out of policy. | Complete incident reporting or regulatory notification workflow. | Lifecycle state change, quarantine note, revocation event, decommission record. |
| Lifecycle state changes | The device moved through active, transferred, quarantined, revoked, or decommissioned states. | All device-operations monitoring evidence. | Lifecycle history and audit log. |
| Evidence summary | Device-trust controls are traceable across identity, certificates, updates, and lifecycle state. | Complete technical documentation package, CE marking, or conformity assessment. | Exportable evidence summary or audit bundle. |
How device-trust evidence supports CRA readiness — without replacing the full programme
QuarkLink connects the device-trust record
QuarkLink keeps identity, certificate, update, revocation, and lifecycle records connected so product-security and compliance teams can discuss device trust with concrete evidence.
Broader evidence remains separate
SBOMs, vulnerability handling, incident response, and conformity workstreams remain separate, but the device-trust record gives them concrete operational evidence to reference.
Build evidence from the workflow
Start with real device workflows, then retain the records needed for technical documentation, customer assurance, and support-period review.