Direct answer

Give every device a unique credential. Use certificates when delegated trust, interoperable mutual TLS, or independent verifier relationships justify a public-key infrastructure. Use unique symmetric keys when devices and one tightly controlled service share a simpler trust domain and constrained hardware makes public-key operations impractical. The decisive issue is not credential format but secure provisioning, hardware protection, rotation, revocation, recovery, and retirement at fleet scale.

Scope and non-scope

This comparison covers device authentication credentials. It does not decide user identity, payload encryption, firmware signing, or authorization. A valid certificate proves possession of a private key and binds attributes according to policy; it does not automatically grant topic or tenant access.

Symmetric-key model

A unique symmetric key can support challenge-response or establish a secure channel through a defined protocol. It avoids certificate parsing and can fit constrained secure elements. The verifier must possess or derive secret material, which concentrates risk. Never use one fleet-wide key: compromise of one device would enable impersonation of all peers and make selective revocation impossible.

Define whether the backend stores each key, derives it from a protected master, or delegates verification to an HSM. A derivation design needs domain separation and a way to revoke one device without exposing the master. Operators and application databases should not read raw keys.

Certificate model

Each device holds a private key and a certificate signed by a trusted issuer. Verifiers can authenticate without knowing the private key, and certificate chains support manufacturing or product subordinates. Certificates carry issuer, subject or device identifiers, validity, key usage, and policy constraints. They add CA governance, enrollment, chain validation, time handling, and trust-store lifecycle.

For devices without reliable clocks, plan certificate validity checks deliberately rather than disabling them. Rotation can use overlapping trust and proof of existing key or an enrollment authority. Protect CA keys separately from online enrollment services and constrain subordinate issuers by product and purpose.

Decision criteria

Assess hardware key protection, manufacturing environment, number of independent verifiers, offline verification, supported TLS stacks, message and handshake cost, device lifetime, ownership transfer, regulatory needs, and incident response. Measure the exact algorithm and chain on target hardware; avoid generic claims that one approach is always lighter.

Lifecycle procedure

  1. Create unique identity and credential material in a controlled provisioning boundary.
  2. Bind it to hardware, product, and manufacturing evidence.
  3. Keep private or symmetric keys non-exportable where hardware supports it.
  4. Activate ownership separately from immutable product identity.
  5. Authorize from server-side device and tenant records, not certificate text alone.
  6. Rotate before expiry or cryptographic deprecation with overlap and rollback.
  7. Revoke compromised devices within a documented enforcement window.
  8. Reset, transfer, and retire devices without resurrecting old ownership.

Failure modes

A copied factory key creates clones. A certificate can be valid but mapped to the wrong tenant. Revocation lists are ineffective when verifiers never refresh them. A device with a bad clock can reject every renewed certificate. Recovery credentials stored beside the primary key may fail together. A CA compromise has a wider blast radius than one device key, while a symmetric verifier breach may expose many device secrets.

Implementation checklist

  • Every device has unique, inventory-bound credentials.
  • Keys are generated and stored inside a documented trust boundary.
  • Authentication and authorization mappings are separate.
  • Rotation, overlap, revocation, ownership transfer, and retirement are tested.
  • CA or symmetric master material is HSM-protected and tightly governed.
  • Clock loss and long offline periods have an explicit policy.
  • Algorithms and chain sizes are tested on target hardware and networks.
  • Compromise drills prove selective containment.

Provisioning and incident evidence

Preserve a per-batch record of the provisioning system version, issuer or derivation domain, hardware key slot, identity binding, and verification result without exporting secret material. Sample finished devices to prove that identities are unique and the backend maps them to the correct product record. Test failed provisioning so partially created identities cannot later activate.

For incident readiness, measure how long it takes to block one credential, one manufacturing batch, and one issuing hierarchy while unaffected devices continue operating. Rehearse rotation after a device has been offline beyond the normal renewal window. Record which services cache authentication or revocation decisions and their maximum stale period. The meaningful security property is contained compromise over the full lifecycle, not simply that mutual authentication succeeded once.

Review cryptographic agility without promising effortless algorithm swaps. Record supported primitives, key sizes, secure-element limits, protocol negotiation, and update dependencies. A future migration needs overlapping trust and tested device code; a database field named algorithm is not a fleet transition plan.

Primary sources

NISTIR 8259A defines device identification and configuration capabilities. NIST SP 800-57 Part 1 covers cryptographic key-management principles, and RFC 5280 defines the Internet X.509 certificate and CRL profile. Use the applicable protocol profile and hardware vendor documentation for implementation.