For any modern internet-facing IoT device, web portal, or consumer application, passkeys are the undisputed winner because they eliminate phishing and credential stuffing by anchoring the private key in hardware. However, for legacy industrial protocols (like Modbus RTU), raw serial links, or ultra-low-cost microcontrollers lacking a secure element, passwords (shared secrets) remain the mandatory choice due to protocol limitations and silicon costs. Understanding the hardware-level difference between passkeys and passwords is no longer just a software concern; it dictates your PCB BOM, your flash memory architecture, and your physical attack surface.

The Single Physical Difference That Drives Everything

The single physical difference that drives all other distinctions is silicon-bound asymmetry versus transmissible data.

A password is a symmetric shared secret. It is simply an array of bytes stored in standard Non-Volatile Storage (NVS), SPIFFS, or EEPROM. To authenticate, the microcontroller must read those bytes into RAM and transmit them across the wire (ideally wrapped in TLS). Because the password exists as plaintext or reversibly encrypted data in the MCU's memory space, it can be dumped via UART, read via JTAG, or extracted by desoldering the SPI flash chip and reading it with a SOIC8 clip.

A passkey (implementing FIDO2/WebAuthn standards) relies on asymmetric public-key cryptography where the private key is physically trapped inside a Secure Element (SE), Trusted Platform Module (TPM), or Secure Enclave. The private key is generated inside this isolated silicon and mathematically cannot be extracted. When a server issues a cryptographic challenge, the main MCU passes the challenge over an I2C or SPI bus to the Secure Element. The SE signs the challenge internally and returns only the signature. The private key never touches the main MCU's RAM, meaning physical memory dumps yield zero authentication material.

Bench Note: I've seen countless 'secure' IoT prototypes compromised because the WiFi PSK or MQTT broker password was stored in an ESP32's default NVS partition without flash encryption enabled. A $15 USB-to-UART adapter and the esptool.py command line is all an attacker needs to read the entire flash contents and extract the password. Passkeys make this specific physical attack vector entirely moot.

Passkeys vs Passwords: Hardware & Protocol Comparison

This table maps the theoretical differences to the physical realities of embedded systems design and protocol overhead.

Criterion Passkeys (FIDO2 / Hardware Keys) Passwords (Shared Secrets / PSK)
Cryptographic Basis Asymmetric (Public/Private Key Pair, ECDSA/Ed25519) Symmetric (Shared byte array, SHA-256 hashing)
Hardware Requirement Secure Element (e.g., ATECC608B), TPM, or Secure Enclave Standard MCU Flash / EEPROM (No special silicon required)
Wire Transmission Only the cryptographic signature and public key are transmitted The secret itself (or a reversible hash) must traverse the network
Physical Dump Resistance Immune to UART/JTAG/Flash dumping (Key never leaves SE) Highly vulnerable to flash readout unless hardware-encrypted
Protocol Overhead High (Requires TLS, JSON/CBOR parsing, challenge-response) Low (Simple string comparison or basic HMAC handshake)

Where the Two Are Strictly NOT Interchangeable

While the consumer web is rapidly migrating to passkeys, the industrial and embedded sectors face hard physical limitations. You cannot simply swap a password for a passkey in the following scenarios:

  • Legacy Serial Protocols (Modbus RTU, RS-485): A FIDO2 WebAuthn challenge-response requires a bidirectional, relatively high-bandwidth IP connection to handle JSON/CBOR payloads and TLS handshakes. You cannot execute a passkey authentication sequence over a 9600-baud, half-duplex RS-485 bus running Modbus RTU. These systems strictly require pre-shared keys (passwords) or physical layer security.
  • Basic MQTT without Client Certificates: If your MQTT broker (e.g., Mosquitto) is configured for basic username/password authentication over port 1883, it expects a shared secret. While you can use MQTT over TLS with client-side X.509 certificates (which function similarly to passkeys by keeping the private key in a secure element), the standard 'MQTT password' field is inherently a shared secret.
  • Ultra-Low-Power Wake-Radio Nodes: Devices running on coin cells that wake up, transmit a 12-byte payload via LoRaWAN, and go back to sleep do not have the RAM, clock speed, or power budget to perform the elliptic curve cryptography (ECC) required for passkey signing. They rely on AES-128 symmetric keys (passwords) stored in the LoRa module's secure memory.

Cost, Silicon, and Availability Breakdown

Security is always a trade-off against BOM (Bill of Materials) cost and PCB real estate. According to NIST SP 800-63B Digital Identity Guidelines, verifiers should transition to multi-factor and hardware-backed authenticators, but the financial reality of hardware design dictates your choices.

Component Cost Matrix (2026 Estimates):
  • Passwords (NVS Storage): $0.00. Uses existing internal flash. Requires zero additional PCB footprint.
  • Microchip ATECC608B-TNGTLSS: ~$0.45 - $0.65 in bulk. An I2C cryptographic co-processor that securely stores private keys and handles ECC signatures. Requires a 2x3mm DFN footprint on your PCB.
  • ESP32-S3 Internal Secure Boot: $0.00 marginal cost, but requires rigorous manufacturing provisioning (burning eFuses) and complex firmware implementation to act as a root of trust.
  • YubiKey 5C NFC (End-User Token): ~$55.00. Used when the 'passkey' resides in a USB token carried by the human operator authenticating to the IoT management dashboard.

Choose Passkeys When / Choose Passwords When

Use these rules to eliminate fence-sitting during your architecture review.

Choose Passkeys (Hardware-Backed Asymmetric Keys) When:

  • The device connects to the public internet and exposes an API or web dashboard.
  • You are building a consumer product where physical device theft could lead to cloud account compromise.
  • Your compliance framework (e.g., HIPAA, SOC2, or modern FIDO Alliance standards) explicitly mandates hardware-backed multi-factor authentication.
  • You have the BOM budget for a $0.50 Secure Element and the firmware expertise to implement I2C crypto-auth libraries.

Choose Passwords (Symmetric Shared Secrets) When:

  • You are communicating over raw serial (RS-232/RS-485), CAN bus, or low-bandwidth LPWAN (LoRa/Sigfox).
  • The device is physically air-gapped inside a locked, access-controlled industrial control panel.
  • Your MCU lacks the RAM to handle TLS handshakes and ECC math (e.g., 8-bit AVR or low-end Cortex-M0).
  • You are provisioning thousands of nodes in the field via a simple CSV file of pre-shared keys (PSKs) and lack a secure manufacturing provisioning line.

The Embedded Engineer's Decision Path

Follow this decision tree to arrive at your exact hardware and authentication implementation.

Condition / Environment Protocol Constraint Terminating Decision (Concrete Pick)
Internet-facing consumer IoT hub or smart lock HTTPS / MQTT over TLS Pick: ESP32-S3 + Microchip ATECC608B (Passkey/FIDO2)
Operator accessing the device's local web UI HTTP/HTTPS Browser Auth Pick: YubiKey 5 NFC (WebAuthn Passkey)
Factory floor sensor on a daisy-chain bus Modbus RTU over RS-485 Pick: STM32 NVS Pre-Shared Key (Password)
Battery-powered agricultural soil probe LoRaWAN MAC layer Pick: Semtech SX1262 AES-128 AppKey (Password/PSK)
High-security industrial gateway (internal network) OPC-UA / MQTT Pick: Infineon OPTIGA TPM 2.0 (Hardware Certificate/Passkey)

For a deep dive into securing the underlying flash storage where these credentials reside, consult the Espressif Flash Encryption documentation to ensure your symmetric passwords aren't trivially readable via SPI bus sniffing.