Identity and provisioning
Who the device is, how its trust was created, and which onboarding target was approved.
Device-trust evidence for technical documentation
Turn device-trust workflows into evidence teams can use
Compliance conversations need proof, not just controls. For connected products, useful evidence often sits around provisioning records, certificate history, update authorization, revocation, quarantine, decommissioning, lifecycle state changes, and audit summaries.
What belongs in a device-trust evidence pack
Certificates and access
Which credentials were valid, renewed, rotated, expired, or revoked over the support period.
Updates and integrity
Which signed firmware was authorized, which devices were eligible, and what happened during rollout.
Lifecycle decisions
Why devices were quarantined, revoked, transferred, or decommissioned.
Evidence accumulates across the lifecycle
ProvisionedCertificate issuedUpdate authorizedState 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, authorize updates, change lifecycle state, revoke trust, and export records for review.
Product proof: evidence export summary
This proof panel shows the shape of a device-trust evidence export: identity, certificate state, update authorization, revocation, lifecycle history, and audit summary in one reviewable record.
Device-trust record for technical documentation
Provisioning job, certificate request, and first connection.
Issuance, renewal, expiry, rotation, and revocation history.
Signed firmware, eligibility rule, rollout status, and result.
Trust removed or constrained for risky or retired devices.
Active, transferred, quarantined, revoked, or decommissioned.
Exportable record for assurance and documentation review.
Evidence item to proof point
| 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 authorization and status | A signed firmware release was authorized 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 operational monitoring or fleet-management 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. |
What this evidence supports, and what it does not replace
Device-trust evidence complements SBOM, vulnerability-management, incident-response, and conformity evidence. It does not replace the full technical documentation package, CE marking, conformity assessment, product risk assessment, source-code security, or regulatory reporting workflows.
How QuarkLink owns 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.
How it complements broader evidence
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 a real device workflow, then retain the records needed for technical documentation, customer assurance, and support-period review.