Manufacturing
Provision devices during factory or programming-line workflows with repeatable jobs, controlled key boundaries, and batch records.
Secure provisioning for connected devices
Make provisioning the start of the device-trust lifecycle
Secure provisioning is where a connected device becomes a trusted product. It creates the hardware-rooted identity, per-device credentials, certificate record, key boundary, and first route into cloud or broker services.
Provisioning contexts
First boot
Create or activate identity when the device first runs, then bind credentials and policy to the intended product family.
First connection / cloud onboarding
Register the device with AWS, Azure, MQTT, private services, or customer infrastructure using mutual authentication.
Provisioning lifecycle
Generate keyIssue identityRegister certificateOnboard targetRecord first connectionStart lifecycle record
A secure provisioning workflow should turn key generation, certificate issuance, onboarding, and first connection into a record that the rest of the device lifecycle can use.
Provisioning sequence
| Step | Decision | Evidence to retain | QuarkLink support |
|---|---|---|---|
| 1. Establish the key boundary | Decide whether keys live in device storage, secure element, SRAM PUF, HSM-backed process, or another approved trust boundary. | Key-generation method, trust anchor, target hardware, policy owner. | QuarkLink Device SDK and provisioning workflow connect hardware-rooted identity to the lifecycle record. |
| 2. Issue per-device identity | Generate or register a unique device identity and bind it to the intended product, batch, or device family. | Device identity, certificate request, issued certificate, device group. | QuarkLink Cloud records identity, certificate issuance, and intended onboarding target. |
| 3. Automate provisioning | Run the workflow in manufacturing, first boot, CI automation, or a controlled first-connection process. | Batch record, operator or job ID, timestamp, result, retry or failure state. | CLI / API automation reduces manual handling of secrets and creates repeatable records. |
| 4. Onboard to services | Connect devices to AWS, Azure, MQTT, private services, or customer infrastructure using mutual authentication. | Onboarding target, certificate chain, broker or cloud registration, first connection. | QuarkLink links provisioning to cloud or broker onboarding and later lifecycle state. |
| 5. Start lifecycle evidence | Treat provisioning as the first record in the device-trust lifecycle, not a one-time setup task. | Identity, certificate, policy, onboarding target, and lifecycle state history. | QuarkLink keeps provisioning connected to renewal, revocation, updates, quarantine, and decommissioning. |
Product proof: first-connection provisioning record
This proof panel shows the record a secure provisioning workflow should leave behind: identity, certificate, key boundary, onboarding target, first connection, and lifecycle state.
Device first connection
Unique identity bound to product, batch, or device family.
Credential and certificate chain recorded for future lifecycle use.
Device storage, secure element, SRAM PUF, HSM, or approved boundary.
AWS, Azure, MQTT, private service, or customer infrastructure.
Device authenticated and associated with the intended target.
Provisioning becomes the first lifecycle evidence record.
How QuarkLink connects the workflow
Device SDK
Handles device-side trust, hardware-root integration, key generation, secure provisioning, and communication with QuarkLink.
QuarkLink Cloud
Records identity, certificate issuance, onboarding target, policy, lifecycle state, and evidence.
CLI / API automation
Connects provisioning to manufacturing, CI/CD, batch workflows, customer systems, and deployment processes.
Provisioning starts trust. It does not replace update readiness, certificate renewal, revocation, vulnerability handling, incident response, SBOM, or full product risk assessment.
Start with a trusted first device
Use QuarkLink to connect device-side identity, cloud onboarding, and lifecycle evidence before scaling the workflow across product families.