Your authentication strategy was built for browsers, but your attack surface now includes cars, medical devices, and industrial controllers. This gap is where most teams fail.
Why These Mistakes Keep Happening
Connected devices don't fit the mental model most security teams have. You've spent years hardening web applications, implementing OAuth 2.0 flows, and rolling out multi-factor authentication for employees. These patterns don't transfer cleanly to devices lacking screens, keyboards, or consistent network connectivity.
Regulatory requirements add to the challenge. UNECE WP.29 sets baseline requirements for vehicle software updates and data protection. The U.S. federal government's IoT labeling program pushes manufacturers to build more secure products from the start. Compliance teams often translate these requirements into checkbox exercises rather than architectural changes.
Most organizations discover their mistakes only after an incident. Here's what teams get wrong and how to fix it before you're writing the incident report.
Mistake 1: Treating Device Authentication Like User Authentication
You're applying browser-based authentication patterns to devices that will never see a login screen. Teams implement OAuth 2.0 Authorization Code Flow with Proof Key for Code Exchange for a sensor that has no display and no user. The device can't complete the interactive flow, so engineers hardcode credentials or create workarounds that bypass security controls.
Why it happens: Your identity platform was purchased to solve workforce identity. The vendor demo showed employees logging into SaaS applications. Device identity was an afterthought.
Real consequence: Devices authenticate with long-lived API keys stored in firmware. When you need to rotate credentials across 50,000 deployed sensors, you find there's no remote update mechanism that doesn't require physical access.
The fix: Implement device identity separately from user identity. Use client credentials flows with certificate-based authentication for machine-to-machine communication. Your Policy Decision Point should evaluate device posture separately from user context. If the device can attest its state cryptographically, require it. If it can't, segment it accordingly.
Mistake 2: Assuming Physical Access Equals Trusted Device
Your car's infotainment system trusts any USB device plugged into the port. Your building management system trusts any device on the maintenance VLAN. You're conflating physical proximity with authentication.
Why it happens: Operational technology teams come from a world where physical security was the security boundary. If someone had badge access to the server room, they were authorized. That assumption doesn't hold when the "server room" is a charging port in a parking garage.
Real consequence: An attacker with temporary physical access installs a rogue device that maintains persistent access after they leave. Your access logs show legitimate physical entry, so the security team doesn't investigate.
The fix: Require cryptographic device identity even for physically connected devices. Issue Multi-Factor Cryptographic Devices or embedded certificates during manufacturing or provisioning. Your authentication policy should verify device identity, firmware version, and configuration state before granting network access. Physical presence is a factor, not a substitute for authentication.
Mistake 3: Skipping Phishing-Resistant Authentication for Administrative Access
Your connected devices support FIDO2 for end-user authentication, but administrators still log in with passwords and Time-Based One-Time Passwords. You've secured the front door while leaving the service entrance propped open.
Why it happens: Administrative interfaces are "internal tools" that don't face the internet. Teams assume the risk is lower. The authentication vendor charges extra for administrative user licenses with phishing-resistant methods.
Real consequence: An administrator's credentials are phished. The attacker uses those credentials to push a malicious firmware update to your entire device fleet. Your audit logs show a legitimate administrator account performed the action.
The fix: Administrative access to device management platforms requires phishing-resistant authentication. If your vendor doesn't support FIDO2 or certificate-based authentication for admin consoles, escalate the issue. The FIDO Alliance's specifications exist because passwords and OTP codes can be phished. Use them for accounts that can touch production devices.
Mistake 4: Ignoring the Firmware Update Authentication Gap
You've implemented strong authentication for device enrollment and runtime operations. But your firmware update process verifies the update package signature without authenticating the entity requesting the update. Any device that can reach your update server can request and install firmware.
Why it happens: Update systems were designed for availability, not security. The priority was ensuring devices could get critical patches quickly. Authentication was seen as friction that would slow emergency updates.
Real consequence: An attacker triggers a downgrade attack, forcing devices to install older firmware with known vulnerabilities. Or they flood your update infrastructure with requests, creating a denial-of-service condition when you need to push an emergency security patch.
The fix: Require mutual authentication for update requests. The device proves its identity, and the update server proves its identity. Implement rate limiting and anomaly detection on update requests per device identity. Your update policy should verify device state before allowing a downgrade. UNECE WP.29's requirements for vehicle software updates exist because manufacturers learned this lesson the hard way.
Mistake 5: Building a Single Authentication Policy for All Device Types
Your authentication policy treats a medical implant, a smart thermostat, and an industrial robot identically. They all get the same credential lifetime, the same network access, and the same trust level.
Why it happens: Scaling authentication across thousands of device types is complex. Teams create one policy to simplify management. Your identity platform's policy engine doesn't make it easy to segment by device capability or risk profile.
Real consequence: You're forced to choose between security and availability. Set credential lifetimes too short, and devices with intermittent connectivity can't re-authenticate. Set them too long, and compromised credentials remain valid for weeks.
The fix: Segment your device population by capability and risk. Devices that can perform cryptographic operations get short-lived certificates with automated rotation. Constrained devices get longer-lived credentials but limited network access through microsegmentation. Your Policy Administrator should evaluate device type, location, firmware version, and communication patterns before granting access. Build separate policies for each device class, not one policy with exceptions.
Mistake 6: Forgetting That Devices Outlive Your Authentication Infrastructure
You're issuing device credentials tied to an authentication service you'll decommission in three years. The devices will remain in service for a decade.
Why it happens: Device lifecycle planning doesn't include identity infrastructure dependencies. Procurement evaluates the device's hardware warranty, not its authentication dependencies.
Real consequence: You need to migrate authentication providers, but you can't remotely update device configurations. You're stuck running parallel authentication infrastructure or planning a costly device replacement program.
The fix: Before deploying devices, document their authentication dependencies and expected service life. If a device will operate for ten years, ensure its authentication mechanism can evolve. Use standards-based protocols (FIDO2, OAuth 2.0, certificate-based authentication) rather than vendor-specific implementations. Build remote configuration update capabilities into devices before deployment. Your device procurement checklist should include "authentication migration path" as a requirement.
Prevention Checklist
Run this checklist before deploying a new connected device category:
- Device authentication uses cryptographic identity, not shared secrets
- Physical access does not bypass authentication requirements
- Administrative interfaces require phishing-resistant authentication
- Firmware updates require mutual authentication between device and server
- Authentication policy segments devices by capability and risk profile
- Device service life is shorter than authentication infrastructure commitment, or remote credential updates are possible
- Compliance requirements (UNECE WP.29, IoT labeling program) are mapped to specific authentication controls
- Vault Rotation procedures exist and have been tested
- Policy Decision Point evaluates device posture, not just identity
- Incident response plan includes device credential compromise scenarios
Your browser-based authentication strategy won't protect the devices your organization is deploying. Fix these mistakes now, before regulators or attackers force the issue.
