What is the difference between factory provisioning and runtime enrollment?

Factory provisioning installs the device's cryptographic identity during manufacturing — keys generated in secure hardware, a long-lived certificate (typically an IEEE 802.1AR IDevID or Matter DAC) issued by a factory-integrated CA, and trust anchors written to device storage before shipping. Runtime enrollment issues certificates on demand over the network after deployment, using an enrollment protocol like EST, ACME, BRSKI, or CMPv2. They are different architectures, not alternatives. A production device typically uses both: factory provisioning for the foundational identity, runtime enrollment for operational certificates.

When is factory provisioning mandatory?

Factory-installed identity is effectively mandatory under several regulatory and ecosystem requirements: the EU Cyber Resilience Act for products with digital elements on the EU market, the Matter specification (which requires a CSA-recognised Device Attestation Certificate installed at manufacture), the US Cyber Trust Mark guidance via NIST 8259A, IEEE 2030.5 for smart grid endpoints, and 3GPP specifications for 5G and LTE equipment. If a device is subject to any of these, factory provisioning is table stakes; runtime enrollment supplements but does not replace it.

What is BRSKI and when is it used?

BRSKI (Bootstrapping Remote Secure Key Infrastructure, RFC 8995) is a protocol for bootstrapping a device into an operator's PKI at first deployment using a voucher exchange with a manufacturer-operated MASA. It assumes the device has a factory-installed IDevID and gives the operator a standard way to transfer trust from the manufacturer to itself, then enroll an operator certificate via EST. BRSKI is currently concentrated in enterprise networking equipment and is the right answer for enterprise bring-up of devices from multiple manufacturers. It does not eliminate factory provisioning; it adds ceremony around trust transfer.

Can one CA hierarchy handle both factory provisioning and runtime enrollment?

Yes, with profile-based policy and a CA architecture that supports both bulk/offline issuance and online protocol-driven issuance. The factory issues long-lived IDevIDs or DACs through an HSM-integrated, manufacturing-network provisioning pipeline; the runtime CA issues LDevIDs and operational certificates via EST or ACME. The unified PKI must distinguish factory issuance from runtime issuance in audit, support hardware attestation binding for factory certificates, and expose an API or offline mode suitable for factory integration — not just web-facing enrollment endpoints.

Factory Provisioning vs Runtime Enrollment: When Each Model Is the Right One

Mass provisioning during manufacturing and on-demand runtime enrollment are different PKI architectures, not alternatives. The decision matrix: device class, connectivity, manufacturing partner trust, regulatory driver. When to use each, when to combine them, and where the hybrid boundary sits.

Factory provisioning and runtime enrollment are often discussed as if they were alternatives — a design choice where an organisation picks one. They are not alternatives. They are different architectures for different layers of the device identity stack, and a production device typically uses both: factory provisioning for the foundational identity, runtime enrollment for operational certificates. The question is not which to choose but where the boundary between them sits.

Featured Tool Runs fully in-browser

PKI Health Radar

Drag the sliders to assess your current posture — scores update instantly.

6 more tools: Cost & Risk Explorer Timeline Builder Shadow Heatmap Process Transform Slider Scenario Comparator What-If Demo All tools & guide →

This decision matters because the two models have almost nothing in common operationally. Factory provisioning is bulk, offline, manufacturing-integrated, high-trust, and expensive to get wrong. Runtime enrollment is streaming, online, protocol-driven, authenticated by existing credentials, and cheap per transaction. A unified PKI must support both, distinguish between them in policy, and make the boundary between them explicit in the operational model.

For deeper technical detail on factory provisioning mechanics, see device identity factory provisioning. This page frames the decision: when each model is appropriate, how they combine, and what drives the boundary placement.

The two models, operationally

Factory provisioning

The device's cryptographic identity is generated and installed during manufacturing. The typical flow:

A key pair is generated on the device's secure element, TPM, or secure enclave. The private key never leaves the hardware.
The device emits a certificate signing request (CSR) to the factory provisioning infrastructure.
The factory provisioning CA — either operated by the manufacturer, by the operator, or by a specialist provider — issues a certificate.
The certificate is written to device storage alongside any required trust anchors.
The device is tested, packaged, shipped.

The certificate is typically an IEEE 802.1AR IDevID for enterprise and industrial devices, or a Matter Device Attestation Certificate (DAC) for Matter-ecosystem devices. In both cases the validity is long — 10 to 30 years (contrasting with the enterprise trajectory of 47–200 days under SC-081v3) — because the certificate must outlast the operational life of the device.

The infrastructure sits on the factory floor, integrated with manufacturing execution systems, often behind production network isolation, sometimes at multiple contract manufacturers in multiple countries. It is not a web service. It is a manufacturing process step with PKI inside it.

Runtime enrollment

The device requests a certificate from the operator's CA after deployment, over the network, using some form of authentication that the CA accepts. The typical flow:

The device presents an existing credential — usually its IDevID — to the enrollment endpoint.
The device generates a new key pair (the operational key) in secure hardware.
The device submits a CSR authenticated by the IDevID.
The CA issues an operational certificate — typically an LDevID.
The device uses the LDevID for operational network authentication.

Enrollment protocols: EST (RFC 7030) for IDevID-authenticated device enrollment, ACME (RFC 8555) for gateway or server endpoints, BRSKI (RFC 8995) for zero-touch bootstrap when no factory identity exists, CMPv2 (RFC 4210) for telco device enrollment. See PKI enrollment protocols for enterprise and IoT for the protocol choice.

Runtime enrollment is a web service. It scales differently, fails differently, and operates at a different cadence than factory provisioning.

Decision matrix for factory provisioning versus runtime enrollment across regulatory regime, device class, manufacturing model, and operator trust — with cells indicating the recommended provisioning model. — Figure 2 — When factory provisioning is mandatory, when runtime enrollment is sufficient, and when both are required.

The decision: what drives each choice

Four factors dominate the decision of where the boundary between factory provisioning and runtime enrollment sits.

Regulatory driver

Some regulations mandate factory-installed identity. These are the cases where factory provisioning is not optional.

EU Cyber Resilience Act (Regulation (EU) 2024/2847): products with digital elements placed on the EU market must have secure-by-design identity. In practice this is interpreted as requiring hardware-backed identity installed during manufacturing, not provisioned on first boot.

Matter (CSA): requires a Device Attestation Certificate issued by a CSA-recognised PAA/PAI chain, installed during manufacturing. Runtime-provisioned DACs are non-compliant.

US Cyber Trust Mark: product eligibility for the mark requires secure device identity per NIST 8259A and related guidance. Factory-installed identity is the practical interpretation.

IEEE 2030.5-2023 / smart grid: the smart energy profile IEEE 2030.5 requires device certificates issued under a utility-approved PKI, typically installed during manufacturing to meet utility interconnection requirements.

3GPP / telecom: 5G and LTE device equipment requires vendor-signed identity from manufacturing, with operator enrollment of operational credentials runtime.

If the device is subject to any of these, factory provisioning is table stakes. Runtime enrollment supplements but does not replace it.

Device class and constraint

Device compute, memory, and connectivity determine what the device can do at runtime.

Highly constrained devices (512KB RAM or less, intermittent connectivity): cannot reliably run a full enrollment protocol at runtime. Factory provisioning installs all the certificates the device will ever need. Updates happen via firmware replacement, not certificate rotation.

Constrained connected devices (typical consumer IoT, enough compute for TLS and basic enrollment, reliable-enough connectivity): factory-installed IDevID + runtime LDevID enrollment via EST. The IDevID anchors trust; LDevIDs rotate.

Capable devices (industrial gateways, edge compute, connected vehicles with substantial compute): factory-installed IDevID + runtime enrollment of multiple certificate types — TLS, MQTT, workload identity. The device looks more like an enterprise endpoint than a constrained thing.

Server-class endpoints (cloud VMs, Kubernetes workloads, edge servers): no factory provisioning in the manufacturing sense; the device is a software instantiation. SPIFFE/SPIRE or ACME handles identity entirely at runtime.

Connectivity posture at first boot

Where does the device first connect to a network, and what does it expect to find there?

Factory network only: devices that complete provisioning on the factory floor and ship with identity already installed. No reliance on deployment-time infrastructure. Common for consumer IoT where first-boot experience must work regardless of the deployment network.

Manufacturer's activation service: devices that complete initial identity during manufacturing but contact a manufacturer-operated activation service on first boot. Adds runtime enrollment for a fleet management identity. Common for connected appliances, vehicles, industrial gear.

Customer's provisioning network: devices that rely on the customer's DHCP and a zero-touch provisioning flow, typically BRSKI. The device has a factory-installed IDevID and uses BRSKI to bootstrap into the customer's PKI. Common in enterprise networking gear.

Matter commissioning: Matter devices arrive with a factory-installed DAC and complete fabric commissioning on first deployment, receiving a NOC from the fabric administrator. The DAC is factory; the NOC is runtime.

Manufacturing partner trust

Devices manufactured in-house by the operator involve no cross-organisational trust. Devices manufactured by contract manufacturers require explicit trust distribution, and the distribution mechanism shapes the factory provisioning architecture.

Owned manufacturing: factory provisioning CA runs in the operator's control, keys under operator HSM. Straightforward architecturally; rare in practice because most connected product companies use contract manufacturers.

Trusted contract manufacturer: manufacturing partner operates an issuing CA for the operator, under contractual and audit controls. Operator retains root CA control. Most common pattern for enterprise-class connected products. Requires secure distribution of signing capability — typically via HSM deployed at the manufacturing site or via networked access to an operator-managed provisioning service.

Multi-tenant contract manufacturer: manufacturer provisions devices for many customers, running a shared provisioning infrastructure. Each customer gets a subordinate CA under the manufacturer's or a neutral provider's root. Common for high-volume consumer IoT. Trust model depends on the neutral provider's audit posture.

Specialist provisioning provider: organisations like GlobalSign, Sectigo, DigiCert, Device Authority operate provisioning-as-a-service infrastructure that contract manufacturers integrate with. The operator outsources the provisioning PKI but retains policy control.

The trust model determines who holds what keys, where the audit trail lives, and what happens if a manufacturing partner relationship ends. These are not small questions. Factory provisioning contracts typically include CA transition clauses specifying how signing capability returns to the operator at contract termination.

The boundary: what goes in the factory, what runs at runtime

The working pattern for production-class connected devices:

In the factory:

IDevID (or DAC for Matter) — the foundational identity, long-lived, hardware-backed.
Root and intermediate CA certificates the device needs to verify peers.
Any ecosystem-specific certificates required for operation (Matter PAI certificates, for example).
The device serial number in a form bound to the IDevID.

At runtime:

LDevID(s) for operational network authentication.
Workload- or service-specific certificates (per-application TLS, MQTT credentials, application-layer certificates).
Matter NOC after fabric commissioning.
Rotating short-lived credentials for specific protocols.

The boundary is the trust anchor. Anything that must persist across CA rotation, ecosystem changes, or operational certificate compromise goes in the factory. Anything that can be re-enrolled from the trust anchor goes at runtime.

The BRSKI pattern for devices without factory identity

BRSKI (RFC 8995) — Bootstrapping Remote Secure Key Infrastructure — addresses the case where a device either has no factory-installed identity or has an identity from a manufacturer the operator doesn't trust. The device bootstraps into the operator's PKI at first deployment, using a voucher exchange with a manufacturer-operated MASA (Manufacturer Authorised Signing Authority) to prove its identity, then enrolls an operator certificate via EST.

BRSKI is the standardised answer to "how do we add factory-quality trust to runtime enrollment?" Its deployment is currently concentrated in enterprise networking equipment (Cisco's implementation is well-known) rather than consumer IoT, but the pattern is the right answer for enterprise bring-up of devices from multiple manufacturers.

BRSKI requires:

Manufacturer operates an MASA that the operator can reach.
Device has a factory-installed IDevID (BRSKI does not eliminate factory provisioning; it adds ceremony around trust transfer).
Operator has a registrar that issues vouchers and orchestrates the enrollment.
Network path from device to registrar at bootstrap time.

BRSKI is not zero-touch in the consumer sense. It is zero-touch for an enterprise network operator who pre-configures the registrar; the device plugs in and joins the network without manual cert installation. This is a substantial operational win in enterprise deployments.

Hybrid patterns and anti-patterns

Working patterns

Factory IDevID → Runtime LDevID: the canonical model. Factory installs the 802.1AR IDevID; runtime EST enrolls LDevIDs for operational use. LDevIDs rotate on a schedule that matches the operational risk model. Used in enterprise networking, industrial control, and capable IoT.

Factory DAC → Runtime NOC: the Matter model. Factory installs the DAC from a CSA-recognised chain; commissioning installs the NOC from the fabric administrator. Device operates with both — DAC for attestation, NOC for fabric operations.

Factory bootstrap credential → BRSKI enrollment: the zero-touch enterprise networking model. Device ships with a minimal factory identity sufficient for BRSKI voucher exchange; operational enrollment happens via BRSKI + EST at deployment.

Factory provisioning + cloud activation: common for connected appliances. Factory installs hardware identity; first boot contacts the manufacturer's activation service for operational credentials. Combines manufacturer control with runtime flexibility.

Anti-patterns

No factory identity, runtime enrollment with shared secret: the device ships with a shared enrollment secret baked into firmware. Every device from the production run has the same secret, or secrets are derived from serial numbers via an algorithm that leaks. Discovered in many consumer IoT products; responsible for numerous breach reports. Fails ETSI EN 303 645 basic requirements.

Factory identity, but keys not in hardware: IDevID installed during manufacturing, but the private key is stored in plain flash. An attacker with physical access extracts the key. Defeats the purpose of factory provisioning. Common in cost-optimised devices that have hardware identity theatre without hardware identity substance.

Factory identity, but not bound to serial number: the IDevID is issued during manufacturing but not bound to a verifiable serial number or device identifier. Traceability fails. Counterfeit devices with legitimate-looking IDevIDs cannot be distinguished from authentic devices.

Runtime enrollment with no authentication: the enrollment endpoint accepts any CSR and issues a certificate. Turns the CA into a certificate-as-a-service for anyone who finds the endpoint. Has happened in production.

What this means for unified PKI platform selection

Platform evaluation for factory-plus-runtime support:

Can the platform support both factory provisioning (bulk, offline or isolated, HSM-integrated) and runtime enrollment (online, protocol-driven) with the same CA hierarchy?
Does the platform expose an API or offline provisioning mode suitable for factory integration, not just web-facing enrollment endpoints?
Can the platform enforce that factory-issued certificates bind to hardware attestation (TPM quote, secure element challenge)?
Does the audit trail distinguish factory issuance from runtime issuance?
How does the platform handle multi-site, multi-manufacturer factory provisioning with scoped signing authority?
Does the platform support BRSKI for the runtime enrollment bootstrap case, or does it assume pre-existing trust?

Platforms optimised for enterprise enrollment typically fail the factory integration questions. Platforms optimised for device provisioning typically lack the runtime enrollment protocol breadth. The unified platform does both, or the operator runs two platforms with a shared control plane — Architecture B from the unified PKI pillar.