How should organisations use device certificates to secure IoT deployments that still rely on passwords?

Organisations should treat device certificates as cryptographic identities for IoT endpoints, not as an optional add-on. Passwords are weak for connected devices because they are hard to govern at scale and easy to reuse or expose. Certificates support stronger authentication for smart meters, traffic systems, and connected vehicles, and they make it easier to manage trust, provisioning, and lifecycle controls across large device fleets.

Why device certificates fit IoT better than shared passwords

Device certificates give each endpoint a cryptographic identity, which is the right mental model for IoT fleets. Unlike passwords, certificates can be issued to a specific device, validated automatically by infrastructure, and tied to revocation or replacement events. That makes them more suitable when devices are numerous, headless, distributed, and expected to stay in service for years.

For practical machine identity guidance, organisations can use the Machine Identity, PKI and Certificate Lifecycle Guide to understand how lifecycle automation, renewal, and trust anchors fit together. For a broader view of where certificates sit in the identity stack, the Ultimate Guide to NHIs shows how certificates, service principals, and other non-human credentials are governed as identities rather than as ad hoc secrets.

In IoT, the main advantage is trust at scale. Passwords tend to spread, get reused, or end up embedded in scripts and installers. Certificates shift the control point to issuance and validation, so the organisation can decide which devices are allowed to connect instead of relying on a shared secret that may be copied into many places.

How certificates support provisioning, trust, and lifecycle control

Certificates work best when they are part of the device onboarding flow, not something added after deployment. A device can be provisioned with a unique certificate, validated against a trusted issuer, and then monitored through renewal, rotation, or replacement. That creates a clear chain from manufacturing or onboarding through decommissioning, which is much harder to achieve with passwords alone.

For IoT-specific implementation patterns, the Device and IoT Identity Guide is the most direct internal reference because it covers device certificates, attestation, secure onboarding, and lifecycle expectations for connected devices. When the deployment uses workload-style mutual TLS or service-to-service trust, Guide to SPIFFE and SPIRE is useful for understanding how certificate-based workload identity can be issued and verified at runtime.

The operational benefit is that certificate-based trust can be automated even when the device cannot support frequent human interaction. That matters for smart meters, traffic systems, industrial sensors, and connected vehicles, where manual credential management becomes unreliable long before the fleet reaches full scale.

What changes when passwords remain in the environment

Keeping passwords alongside certificates usually means the password becomes the weakest surviving path. Even if certificates are used for primary authentication, leftover passwords can still be reused in maintenance portals, fallback interfaces, provisioning tools, or vendor support workflows. That creates a governance gap because the organisation believes it has modernised authentication while the old secret still grants access somewhere.

Certificates also do not remove the need for revocation, inventory, and expiry management. If a device is retired, compromised, or replaced, the associated certificate must be revoked or allowed to expire in a controlled way. The same discipline applies to private keys, which must be protected as sensitive identity material rather than treated as a deployment detail.

External certificate guidance from the CA/Browser Forum is useful because it reflects the broader industry trend toward shorter-lived certificates and stronger lifecycle discipline. For the key lifecycle side of the equation, NIST SP 800-57 Key Management helps frame certificate-related keys as assets that need generation, protection, rotation, and destruction controls across their full life.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	IA-9 — Identification and Authentication (Non-Organizational Users)	IoT devices are non-organizational endpoints that need device-level authentication.
	IA-5 — Authenticator Management	Certificate private keys and device credentials need lifecycle controls and rotation.
	IA-2 — Identification and Authentication (Organizational Users)	Fallback admin or operator passwords still need strong human authentication.
Recommendation — Use IA-9 to require unique device authentication with certificate-backed trust. Use IA-5 to manage certificate issuance, rotation, renewal, and revocation. Use IA-2 to secure operator access that manages IoT device trust.
ISO/IEC 27001:2022	A.5.15 — Access control	IoT certificates are an access-control mechanism that replaces shared passwords.
	A.8.24 — Use of cryptography	Device certificates depend on correct cryptographic use and key handling.
Recommendation — Define certificate-based access rules and remove shared credential paths. Protect certificate keys and enforce approved cryptographic implementations.

Practitioner Guidance

What to prioritise: Replace shared or default device passwords first on endpoints that can reach production systems or safety-relevant controls. If a password remains necessary during transition, isolate it to provisioning or recovery use and do not let it remain a general-purpose login path.

What to verify: Confirm that each device has a unique certificate, a defined issuer, a renewal path, and a revocation process. If your team cannot answer where certificates are issued, how private keys are protected, and how compromised devices are removed, the deployment is not yet operationally trustworthy.

Common mistake: Treating certificates as a one-time enrollment task. In practice, the security value comes from the lifecycle, not just the initial issuance, so expiry handling, rotation, and retirement need ownership before scale grows.

Practitioner takeaway: Use certificates to make IoT access verifiable and revocable per device, then eliminate passwords wherever they add a fallback path that bypasses that device-level trust model.