Device SDK
Device-side trust, hardware-root integration, secure provisioning, firmware integrity, secure update handling, retry/rollback support where configured, and communication with QuarkLink.
Device-trust workflows for CRA-ready products
The device-trust control plane for CRA-exposed connected products
QuarkLink connects the Device SDK, QuarkLink Cloud, and CLI/API automation so OEMs and partners can provision trusted devices, issue credentials, onboard to cloud and broker targets, govern secure firmware update workflows, manage lifecycle state, revoke or decommission devices, and retain evidence throughout the support period.
One platform across device, cloud, and delivery workflows
The workflows are delivered by three connected layers: device-side trust, cloud control, and automation for manufacturing, deployment, and customer systems.
QuarkLink Cloud
Device identity, certificate lifecycle, policy, trusted update workflows, lifecycle state, revocation, and evidence.
CLI / API automation
Manufacturing flows, CI/CD, provisioning automation, deployment workflows, and integration with customer systems.
Policy
Define device-trust policy
Set device-family policy for identity, certificates, update behaviour, lifecycle states, revocation paths, and the evidence required at each stage.
Identity
Provision device identities
Create hardware-rooted per-device identities, credentials, certificates, provisioning records, and first-connection workflows.
Onboarding
Onboard trusted devices
Connect trusted devices to approved cloud, MQTT broker, private, or customer-hosted services using certificate-backed mutual authentication.
Updates
Govern firmware updates
Sign firmware, check device eligibility, configure rollout rules, support retry or rollback paths, and retain update evidence.
Lifecycle
Operate device trust
Track active, revoked, quarantined, transferred, and decommissioned states as device trust changes over time.
Evidence
Retain audit evidence
Surface provisioning records, certificate history, update events, revocation actions, audit logs, and evidence exports for technical documentation and review.
First trusted connection
See how QuarkLink turns provisioning into the first device-trust record, linking device identity, certificate issuance, onboarding target, first connection, and lifecycle start.
Product family: Industrial Controller Evaluation Fleet Platform profile: Renesas RA8M1 MCU Source: CLI automation
01
Device boundary
Generate key
Private key created inside approved device boundary.
02
QuarkLink record
Issue identity
Per-device identity and certificate request linked to product batch.
03
Cloud / broker target
Register target
Device assigned to AWS IoT Core production.
04
Device boundary
First connection
Device authenticates with certificate-backed trust and becomes active.
Provisioning record
retained- Product family
- Industrial Controller Evaluation Fleet
- Platform profile
- Renesas RA8M1 MCU
- Source
- CLI automation via manufacturing station
- Key boundary
- Device-generated key in approved hardware boundary
- Certificate
- QuarkLink Device CA issued
- Onboarding target
- AWS IoT Core production
- Lifecycle start
- state set to active after first connection
Why this matters
Provisioning becomes the first device-trust evidence recordLater certificate renewal, update workflow, revocation, quarantine, and decommissioning events can attach to this record.
Representative QuarkLink app screen. Example data shown.
Cloud and broker onboarding
See how QuarkLink connects trusted devices to cloud and broker targets while retaining the identity, certificate, policy, and first-connection records behind each onboarding event.
Trusted device cohort
Smart Controller Evaluation Fleet
- Platform profile: STM32H5 MCU
- Per-device certificate issued
- Lifecycle state checked
- Firmware integrity status available
trust policy
QuarkLink trust policy
Onboarding rules
mTLS required certificate active state = active target approved
Only devices with valid identity, certificate state, and lifecycle status can be registered to the selected target.
target registration
Thing registry and certificate mapping created.
Device identity prepared for customer tenant.
Client certificate bound to broker policy.
Customer infrastructure target approved.
Onboarding evidence
Identity, certificate, target, policy, and first-connection records retainedRepresentative QuarkLink app screen. Example data shown.
Signed firmware update workflow
Track how a signed firmware release moves from signing and eligibility checks to controlled rollout, retry or rollback handling, device-state tracking, and evidence retention.
Platform cohort Renesas RA8M1 MCU
Signed artifact controller-fw-2.4.1-security.bin
Eligible cohort 8,203 devices
1
Artifact signed
Firmware package signed against production release policy.
2
Eligibility checked
Device identity, certificate state, lifecycle state, and firmware version evaluated.
3
Eligibility gate passed
Update approved for eligible devices after identity, certificate, firmware, and lifecycle checks.
4
Rollout governed
Staged deployment, retry threshold, pause condition, and rollback path set.
5
Evidence retained
Signing record, eligibility decision, rollout status, and lifecycle events retained.
Evidence bundle
Signing record, eligibility decision, rollout state, verification results, and lifecycle events retainedRepresentative QuarkLink app screen. Example data shown.
Single-device trust record
See how a single device record gives teams one place to review identity, certificates, update state, lifecycle state, and required action.
Trust timeline and evidence history
- Provisioned
Hardware-rooted identity created and certificate issued from approved key boundary.
- Onboarded
Device authenticated to AWS IoT target using active per-device certificate.
- Security update authorized
Firmware 2.4.1 approved after identity, certificate, firmware, and lifecycle checks.
- Response available
Pause rollout, constrain trust, or quarantine on failed verification.
- Evidence retained
Provisioning, certificate, update workflow, and lifecycle records available for assurance review.
Current trust state
update pending- Certificate
- current / renews in 42 days
- Firmware
- 2.3.8 to 2.4.1 security update ready
- Verification
- signed artifact required
- Fallback
- pause or quarantine on failed verification
Next controlled action Apply update or constrain trust
Evidence retained
ready- Provisioning and first-connection record
- Certificate issue and renewal history
- Update eligibility and verification state
- Lifecycle state changes for review
Representative QuarkLink app screen. Example data shown.
Device-trust evidence pack
See how retained lifecycle records can be packaged into evidence for technical documentation, support-period review, customer assurance, and audit preparation.
Evidence summary
Smart Controller Evaluation Fleet
Platform profiles STM32H5 MCU, Renesas RA8M1 MCU
Cloud targets AWS IoT Core, Azure IoT Hub
8,240devices in support period
6evidence record types
42dnext renewal window
Review use
technical documentation support / customer assurance /
support-period review
Provisioning record
retained Device identity and onboarding target were created through a controlled workflow.
Certificate history
retained Certificates can be issued, renewed, expired, and revoked through lifecycle policy.
Update workflow
active Signed security updates are checked for eligible devices and tracked through rollout.
Revocation / quarantine
retained Trust can be constrained or removed when devices are risky, retired, or out of policy.
Export package: device-trust-evidence-smart-controller-fleet.pdf Generated from retained lifecycle records
Representative QuarkLink app screen. Example data shown.
Example evidence outputs
QuarkLink records the device-trust proof points OEMs and delivery partners need for assurance reviews, support-period operations, and technical documentation.
Provisioning job recordCertificate issuance / renewal / revocation historySigned firmware update workflow recordLifecycle state change historyDevice-trust evidence export
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 |
| Secure firmware update workflows | Security updates / automatic-update readiness, vulnerability handling, support period, data integrity | Signed firmware, rollout rule, retry/rollback state, device 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 |
QuarkLink owns device-trust controls, not the whole CRA programme
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
- Secure firmware update workflows, including signing, rollout control, retry/rollback support, and evidence
- 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.
Accountable OEMEmbedded teamsManufacturing teamsCloud teamsProduct-security / PKI teamsODMs and design housesContract manufacturersModule vendors and cloud integrators
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.
AWSAzureMQTTDirect database-backed flowsSecure elementsCI/CDCustomer PKICustomer infrastructureCustomer-hosted / on-prem deployment
Start with Ignite, then move toward production
Use Ignite to evaluate QuarkLink workflows hands-on: provisioning, onboarding, certificate lifecycle, trusted update workflows, lifecycle state, and evidence. When you are ready to scale, compare production plans or contact us for enterprise deployment, HSM, customer PKI, customer-hosted, partner, or complex rollout requirements.