Skip to main content

Consumer Tier 3 — Birth Certificate

App-assisted onboarding with manufacturer-issued birth certificates and device-generated keys via EST.

This is the highest security tier. The manufacturer operates their own PKI and issues a birth certificate to each device during production. The device generates all keypairs on-chip — private keys never leave the device. At setup time, a customer app provisions the device, and the device uses its birth certificate to authenticate with EST via mTLS and submits a CSR for a Glaze operational certificate.

When to use this flow

Use Tier 3 when the manufacturer operates a PKI and the device has hardware-backed key generation (e.g., a secure element or TPM). This provides the strongest identity guarantee: the birth certificate proves hardware authenticity, and the operational private key never leaves the chip. Recommended for critical infrastructure, energy systems, and high-value assets.

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
  • Register device manifest with the Glaze registry (serial, cert fingerprint, hardware revision, batch)

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 (WiFi via BLE/SoftAP provisioning)
  • Persistent secure storage for certificates

Sequence Diagram​

Flow Walkthrough​

Manufacturing​

On the production line:

  1. Device generates birth keypair — The device generates an asymmetric keypair on-chip. The private key never leaves the secure element.
  2. CSR signed by manufacturer CA — The device exports a CSR containing its serial number and public key. The factory sends this to the manufacturer CA, which returns a signed birth certificate.
  3. Device flashed — The birth certificate, manufacturer CA chain, EST URL, and Glaze Root CA are written to the device.
  4. Registry updated — The factory registers the device manifest (serial, certificate fingerprint, hardware revision, batch) with the Glaze registry.

Step 1: Provision via App​

The customer app scans the device and calls the Provision API:

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

The enrollment group defines the tenant, attestation type (birth certificate), and provider configuration. The call is idempotent — returns 201 Created for new devices or 200 OK if already provisioned.

The app provides WiFi credentials to the device over BLE or SoftAP.

Step 2: EST Enrollment​

  1. Fetch CA chain — GET /.well-known/est/cacerts returns the Glaze CA chain.

  2. mTLS with birth cert — The device presents its manufacturer birth certificate as the TLS client certificate. EST verifies the chain against the manufacturer Root CA and looks up the device serial in the registry.

  3. Generate operational keypair — The device generates a new keypair on-chip for the operational certificate. This is separate from the birth keypair.

  4. Submit CSR — POST /.well-known/est/simpleenroll with a PKCS#10 CSR signed by the new private key. EST validates the CSR signature and sends it to the Glaze CA for signing.

  5. Receive operational cert — EST returns the signed operational certificate (PKCS#7), broker URL, and MQTT configuration. The device stores the operational cert alongside its birth cert (retained for factory reset scenarios).

Step 3: Connect to Broker​

The device connects to Mosquitto using mTLS with the Glaze-issued operational certificate and the on-chip private key. The broker extracts the device identity from CN and the tenant from OU for ACL enforcement.

Step 4: Certificate Renewal​

Renewal can be triggered by:

  • Timer — The device tracks certificate expiry and renews proactively
  • MQTT command — The platform sends a renewal command via the command topic
  • Reboot — The device checks certificate validity on startup

For each renewal, the device generates a fresh keypair on-chip, submits a new CSR via POST /.well-known/est/simplereenroll, and receives a new 90-day certificate.

Lifecycle Operations​

The four 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 4 above: Step 4 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 4 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 2 (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. Neither the birth key nor the operational key is ever exported. This is the strongest key protection model.
  • Two independent PKI chains — The manufacturer PKI proves hardware authenticity; the Glaze PKI authorizes platform access. Compromise of one chain does not compromise the other.
  • Birth cert retained — The birth certificate is kept for factory reset scenarios. If the operational certificate is lost or corrupted, the device can re-enroll using its birth certificate.
  • EST trusts both CAs — The EST server validates manufacturer certificates for initial enrollment and Glaze certificates for re-enrollment. The Mosquitto broker trusts only Glaze.
  • Hardware requirement — Requires a secure element, TPM, or equivalent capable of on-chip key generation and CSR creation. This increases device cost but provides the highest security guarantee.

Next Steps​