Devices needing action
4Product workflows for CRA readiness
Device-trust workflows for CRA-exposed connected products
CRA and EU market-access pressure make device trust an operational product requirement. QuarkLink connects the Device SDK, QuarkLink Cloud, and CLI / API automation so OEMs and their development partners can provision trusted devices, issue credentials, authorize security updates, manage lifecycle state, revoke or decommission devices, and retain device-trust evidence.
Product proof: lifecycle state, certificate status, update activity, and evidence
See how QuarkLink brings provisioning, certificate, update, lifecycle state, and evidence signals into one operational view.
Certificates due soon
12Successful OTA jobs
98%| Device group | Platform | Status | Certs | Recent activity |
|---|---|---|---|---|
| ESP32 evaluation kits | MCU / RTOS | warning | 0 / 5 | 3 renewals queued |
| Wurth Cordelia-I pilots | Module | passing | 0 / 0 | Provisioned 2h ago |
| Linux gateway fleet | Embedded Linux | failing | 5 / 6 | OTA retry in progress |
| Factory provisioning line | Mixed devices | failing | 1 / 3 | 2 devices quarantined |
Active lifecycle policies
Production OTA rollout policy
failingCertificate lifecycle baseline
warningRecent activity
View full activity log| 10m ago | Linux gateway OTA rollout paused after retry threshold |
| 32m ago | ESP32 evaluation kits queued for certificate renewal before expiry window |
| 1h ago | Factory provisioning line isolated 2 devices pending re-onboarding review |
Define trust policy
Set product or device-family policy for identity, update rules, lifecycle states, revocation paths, and the evidence expected at each stage.
Provision trusted devices
Create hardware-rooted identity, per-device credentials, secure provisioning records, certificate issuance, and first-connection workflows.
Onboard to cloud and broker targets
Connect devices to AWS, Azure, MQTT, private services, customer infrastructure, and broker targets with mutual authentication.
Authorize security updates
Control signed firmware, update authorization, rollout state, device verification, and update evidence across the support period.
Operate lifecycle state
Track active, revoked, quarantined, transferred, and decommissioned states as device trust changes over time.
Retain evidence
Surface provisioning records, certificate history, update records, revocation events, audit logs, and evidence exports.
How QuarkLink fits together
The workflows are delivered by three connected layers: device-side trust, cloud control, and automation for manufacturing, deployment, and customer systems.
Device SDK
Device-side trust, hardware-root integration, secure provisioning, firmware integrity support, and communication with QuarkLink.
QuarkLink Cloud
Device identity, certificate lifecycle, policy, update authorization, lifecycle state, revocation, and evidence.
CLI / API automation
Manufacturing flows, CI/CD, provisioning automation, deployment workflows, and integration with customer systems.
Deployment workflow templates
Product proof
Show how teams standardize provisioning, certificate lifecycle, update authorization, and evidence workflows across device programmes.
Selected workflows
Secure first provisioning
selectedSigned update release path
selectedAvailable deployment patterns
| Pattern | Typical intent | Workflows | Status | Action |
|---|---|---|---|---|
| QuarkLink Ignite evaluation | Connect a first supported device to cloud or MQTT | 3 | not selected | Start / view |
| Production certificate lifecycle | Renew, revoke, rotate, and evidence device credentials | 4 | not selected | Start / view |
| CRA evidence pack | Retain proof of secure-by-default, OTA, and data integrity | 5 | not selected | Start / view |
CRA-focused product view
QuarkLink makes the compliance relevance explicit by connecting product capabilities to device-trust controls and proof moments. This is product clarity for CRA readiness, not a claim that QuarkLink replaces the full compliance programme.
| Product capability | Helps with these CRA asks | Product proof to show |
|---|---|---|
| Hardware-rooted device identity | Secure by design, secure by default, unauthorised access, technical evidence | Device identity / certificate detail view |
| Secure provisioning and onboarding | Secure by design, secure by default, attack-surface reduction, technical evidence | Provisioning flow, batch record, first-connection view |
| Certificate lifecycle | Unauthorised access, support period, vulnerability handling, evidence | Certificate issuance, renewal, expiry, revocation history |
| Security-update authorization and firmware signing | Security updates / automatic-update readiness, vulnerability handling, support period, data integrity | Signed firmware, update rule, update status, update evidence |
| Firmware integrity / secure boot support | Secure by default, data integrity, attack-surface reduction | Firmware-integrity status or secure-boot enablement proof point |
| Cloud / broker onboarding | Unauthorised access, confidentiality / integrity in transit, deployment readiness | AWS, Azure, MQTT, or broker configuration view |
| Revocation, quarantine, and decommissioning | Vulnerability handling, support period, data removal support, evidence | Lifecycle state and revocation / decommission record |
| Audit logs and lifecycle records | Technical documentation, customer assurance, conformity-support evidence | Audit export, lifecycle history, evidence summary |
From product requirement to lifecycle control
Translate product security requirements into device identity, firmware integrity, update authorization, certificate lifecycle, and evidence controls.
Secure connected-product baseline
On-device key generation
warnMeaning / setting: unique private keys are generated on device
Rationale: private keys should not be copied, emailed, or shared outside the device.
Firmware integrity support
warnMeaning / setting: verified boot is enabled where supported
Rationale: prevent unauthorized or tampered software from running.
Certificate lifecycle
failMeaning / setting: certificate renewal and revocation are automated
Rationale: reduce outages and unauthorised access from stale or compromised credentials.
Signed update release
warnMeaning / setting: firmware packages are signed and encrypted where configured or required
Rationale: devices reject unsigned or tampered updates.
Cloud onboarding
failMeaning / setting: devices connect with mTLS
Rationale: cloned or unauthorised devices should not join services.
Lifecycle evidence
failMeaning / setting: provisioning, update, and revocation records are retained
Rationale: support CRA readiness, audits, and customer assurance.
Evidence and audit
QuarkLink is strongest when it owns the device-trust record. These records support technical documentation, support-period processes, and customer assurance, while the complete technical documentation package remains part of the broader product compliance programme.
What QuarkLink does and does not replace
QuarkLink gives teams the device-trust controls and evidence layer behind CRA readiness for connected products. It also makes the boundary clear so teams can connect QuarkLink to the rest of their compliance and security programme.
QuarkLink helps implement and evidence
- Secure-by-design architecture
- Secure-by-default device trust
- Protected device identity and access
- Signed / authorized security updates
- Firmware integrity
- Certificate lifecycle
- Revocation, quarantine, and decommissioning
- Lifecycle records and audit evidence
QuarkLink does not replace
- Full product risk assessment
- Full SBOM generation and management
- Source-code vulnerability scanning
- Vulnerability disclosure process
- Incident reporting workflow
- Full technical documentation package
- Conformity assessment / CE marking
- Mobile app or cloud application security controls
Built for the teams that deliver device trust
The OEM owns the compliance accountability, but implementation often spans partners. QuarkLink gives that delivery ecosystem a defined device-trust platform instead of a bespoke security stack.
Integrations and deployment proof
QuarkLink is designed to fit into real delivery environments: clouds, brokers, secure elements, CI/CD, customer PKI, and customer infrastructure. Customer-hosted or on-prem deployment is a secondary proof point for enterprise and regulated environments, not the headline category.
Start with Ignite
Self-serve teams can evaluate secure provisioning, onboarding, certificate workflows, and signed update paths on supported hardware.
Move toward production
Compare plans for rollout scope, or contact us for production, enterprise, partner, customer-hosted, HSM, PKI, or complex deployment conversations.