Skip to main content

B2B Tier 3 — Birth Certificate

Pre-provisioned onboarding with manufacturer-issued birth certificates and device-generated keys via EST.

This is the highest security tier for industrial deployments. The manufacturer operates their own PKI, issues a birth certificate to each device during production, and pre-provisions the device to a customer tenant. The device generates all keypairs on-chip — private keys never leave the device. On first network connection at the deployment site, the device self-onboards via EST using its birth certificate for mTLS authentication.

When to use this flow

Use this flow for critical infrastructure, energy systems, and high-value industrial assets where:

  • The manufacturer operates a PKI and the device has hardware-backed key generation
  • Devices are pre-provisioned and deployed without a customer app
  • Maximum security is required: on-device key generation + manufacturer attestation
  • Examples: grid-connected inverters, industrial control systems, medical devices

Prerequisites​

Manufacturer:

  • Operate a PKI (Root CA + Intermediate CA)
  • Share the manufacturer Root CA certificate with Glaze (one-time trust setup)
  • Sign a birth certificate for each device during production
  • Flash each device with: birth certificate, manufacturer CA chain, EST URL, Glaze Root CA certificate, network configuration
  • Register device manifest with the Glaze registry
  • Call POST /api/provisioning for each device during manufacturing

Platform:

  • Beacon Tower EST server deployed and configured to trust the manufacturer Root CA
  • Glaze CA operational
  • Device Registry accessible from EST server

Device hardware:

  • On-chip key generation (secure element, TPM, or equivalent)
  • mbedTLS or similar with CSR (PKCS#10) capability
  • Network connectivity (Ethernet, cellular, or pre-configured WiFi)
  • Persistent secure storage for certificates

Sequence Diagram​

Flow Walkthrough​

Manufacturing + Pre-Provisioning​

On the production line, the manufacturer handles device identity, certificate issuance, and tenant provisioning:

  1. Generate birth keypair — The device generates an asymmetric keypair on-chip.
  2. Sign birth cert — The factory sends the device's CSR to the manufacturer CA.
  3. Flash device — Birth certificate, CA chain, EST URL, Glaze Root CA, and network configuration are written to the device.
  4. Register manifest — The factory registers the device with the Glaze registry.
  5. Pre-provision — The factory calls POST /api/provisioning to bind the device to the customer's enrollment group.
# Register device manifest
curl -X POST https://<onboarding-host>/api/devices/register \
  -H "Authorization: Bearer $MFG_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "device_id": "MFG-SN-2026-00042",
    "cert_fingerprint": "sha256:ab12cd34...",
    "hw_rev": "4.1",
    "batch": "2026-Q1-batch-07"
  }'

# Pre-provision to enrollment group
curl -X POST https://<onboarding-host>/api/provisioning \
  -H "Authorization: Bearer $MFG_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "device_id": "MFG-SN-2026-00042",
    "enrollment_group_id": "<enrollment-group-uuid>"
  }'

Step 1: EST Enrollment​

When the device powers on at the deployment site:

  1. Connect to network — Uses pre-configured Ethernet, cellular, or WiFi settings.
  2. Fetch CA chain — GET /.well-known/est/cacerts returns the Glaze CA chain.
  3. mTLS with birth cert — The device presents its manufacturer birth certificate. EST verifies the chain against the manufacturer Root CA and looks up the device in the registry.
  4. Generate operational keypair — A new keypair is generated on-chip.
  5. Submit CSR — POST /.well-known/est/simpleenroll with a PKCS#10 CSR signed by the new private key.
  6. Receive operational cert — EST returns the Glaze-signed certificate, broker URL, and MQTT configuration.

The entire process is autonomous — no human interaction at the deployment site.

Step 2: Connect to Broker​

The device connects to Mosquitto using mTLS with the Glaze operational certificate and the on-chip private key. The broker extracts device identity and tenant from the certificate fields.

Step 3: Certificate Renewal​

Renewal triggers (timer, MQTT command, or reboot check) are the same as Consumer Tier 3. The device generates a fresh keypair on-chip, submits a new CSR, and receives a new 90-day certificate.

Lifecycle Operations​

The three steps above cover the device-driven happy path. The operations below cover the rest of the lifecycle — admin-driven (revoke, disable, approval gating), device-driven recovery from session loss or shard rotation, and factory-reset recovery when the operational certificate is lost.

Session-loss recovery / shard rotation — POST /reenroll​

Used when the device still holds a valid operational certificate but its MQTT session is broken — broker refused CONNECT, MQTT 5 reason 0x82 (session-taken-over) / 0x9C (use-another-server), or the device woke up after a fleet rebalance and its provider shard moved.

Distinct from Step 3 above: Step 3 is "my cert is expiring, give me a new one." /reenroll is "my cert is fine, tell me where to connect."

POST /reenroll
(mTLS with current operational cert)
StatusMeaning
200Existing routing is healthy — idempotent fast path. Device reconnects with current credentials.
201Routing was refreshed (shard rotation). X.509 credentials are unchanged; rotate via Step 3 if needed.
202Admin approval required — retry after the indicated interval (see below).
403The enrollment group's re-enrollment policy denied the request.
409Re-enroll not supported for the routing target type.
503Provider unavailable — retry with backoff.

Rate-limited per device.

Admin-gated approval​

An enrollment group can be configured to require an admin decision on every re-enrollment. When that gate is active, the device's /reenroll or /.well-known/est/simplereenroll call returns 202 Accepted with a Retry-After header instead of issuing credentials. The device keeps retrying on that cadence until an admin makes a decision:

  1. Admin reads the parked request: GET /api/devices/{deviceRecordId}/pending-reenrollment.
  2. Admin approves or rejects:
    • POST /api/devices/{deviceRecordId}/pending-reenrollment/approve — next device retry mints the cert.
    • POST /api/devices/{deviceRecordId}/pending-reenrollment/reject — next device retry returns 403 until the parked request expires (group-configured TTL).

Use this for fleets where every re-enrollment must trace back to a human decision.

Factory reset / operational-cert loss​

Tier 3 devices retain the birth certificate for the device's lifetime. When the operational cert is lost (factory reset, secure-element wipe, key-store corruption), the device falls back to birth-cert mTLS and re-runs Step 1 (POST /.well-known/est/simpleenroll) with a fresh CSR. No admin action is required unless the enrollment group requires approval, in which case the same 202 Accepted / pending-reenrollment flow applies.

This is the only documented recovery path. If the birth-cert chain itself becomes invalid (manufacturer Root rotated, attestation revoked), the device must be re-introduced via the trust-anchor admin API and is out of scope for the device-firmware contract.

Revoke a device​

Two operations, both admin-only (JWT). Run them together for a full revoke:

EndpointEffect
DELETE /api/devices/{deviceId}Soft-deletes the onboarding device record. Subsequent simpleenroll / simplereenroll / reenroll calls fail.
POST /api/devices/{deviceId}/delete-provider-clientTells the provider to evict the MQTT user + ACL rules. Returns 202 Accepted once queued. The broker rejects subsequent mTLS sessions.

Order matters only for which call returns last; both are idempotent. The birth certificate is not revoked by these endpoints — revoking the birth cert is a manufacturer-PKI concern, not a platform one.

Disable / re-enable​

Soft-delete is the disable mechanism. Restore brings the device back:

EndpointEffect
DELETE /api/devices/{deviceId}Soft-delete (same as revoke). Device cannot enrol, renew, or re-enrol.
POST /api/devices/{deviceId}/restoreUndoes the soft-delete. The current operational cert (if still valid) works again; if expired, the device falls back to birth-cert mTLS + simpleenroll automatically.
POST /api/devices/bulk-delete / bulk-restoreBatch variants (NDJSON body).

Security Considerations​

  • Private keys never leave the device — All keypairs are generated on-chip. The strongest key protection model.
  • Pre-provisioned at factory — No window for unauthorized device claiming.
  • Two independent PKI chains — Manufacturer PKI proves hardware authenticity; Glaze PKI authorizes platform access.
  • Fully autonomous — No app, no human interaction at deployment. The device self-onboards on first network connection.
  • Birth cert retained — Available for factory reset scenarios if the operational certificate is lost.
  • Hardware requirement — Requires a secure element, TPM, or equivalent.

Next Steps​