Iwd vs Wpa Supplicant

iwd and wpa_supplicant both manage WiFi authentication on Linux. We pick the one that does it without dragging a decade of cruft behind it.

The Verdict

iwd wins. Intel built it from scratch to replace wpa_supplicant's aging design, and it shows. It uses the kernel's own crypto and key-management facilities instead of bundling OpenSSL, so the binary is small, the attack surface is narrow, and there's no userspace TLS stack to CVE its way through your patch cycle. Connection times are dramatically faster — iwd routinely associates in a fraction of a second where wpa_supplicant dawdles through scanning and negotiation. It manages its own network profiles, exposes a coherent DBus interface, and integrates cleanly with NetworkManager and systemd-networkd. wpa_supplicant isn't broken — it's just old, sprawling, and configured through a flat file format that feels like 2004. On a system you're building today, picking the incumbent purely because it's the incumbent is how you accumulate the exact debt iwd was written to delete.

Where wpa_supplicant Still Earns Its Keep

Credit where it's due: wpa_supplicant is the most battle-tested WiFi supplicant on Earth. Every distro ships it, every driver expects it, and twenty years of enterprise deployments mean its EAP method coverage is encyclopedic. If you're doing something genuinely weird — niche EAP-FAST/PEAP/TTLS chains, legacy RADIUS quirks, certificate edge cases on locked-down corporate networks — wpa_supplicant has probably hit that bug and shipped the workaround already. iwd's EAP support is good and growing but younger, and a few enterprise configurations still trip it. wpa_supplicant also runs on hardware and embedded targets where iwd's reliance on newer kernel features (proper cfg80211/nl80211 behavior) isn't a safe bet. It is the safe, boring, universally-supported choice. Sometimes boring is exactly what a fleet of routers needs.

Architecture and Dependencies

This is where the gap is starkest. wpa_supplicant carries its own crypto: it links OpenSSL (or GnuTLS/wolfSSL), implements TLS in userspace, and reimplements key-management state machines that the kernel now handles natively. That's a large, slow-moving codebase with a real maintenance and security footprint. iwd offloads cryptography and key management to the kernel and links only a tiny internal library (ell). The result is a supplicant that's an order of magnitude smaller, starts faster, and uses meaningfully less RAM — which matters on routers and embedded gear, not just laptops. iwd also stores network profiles natively instead of demanding you hand-edit a monolithic conf file and HUP the daemon. If you care about provenance, auditability, and a small trusted computing base, iwd's design is simply the more defensible one in 2026.

Operational Reality

Day to day, iwd is nicer to live with. Its iwctl shell is interactive and discoverable — you can scan, connect, and forget networks without memorizing wpa_cli's cryptic syntax or babysitting a control socket. Profiles live in clean per-network files. DBus integration means NetworkManager, systemd-networkd, and ConnMan can all drive it cleanly, and switching NetworkManager's backend to iwd is a single config line. wpa_supplicant's tooling, by contrast, is a museum: wpa_cli, wpa_passphrase, a flat wpa_supplicant.conf, and control sockets you wire up by hand. It works, but every interaction reminds you it predates the conveniences you now expect. The honest caveat: some distros still default to wpa_supplicant and ship it pre-wired, so iwd may cost you ten minutes of setup. Pay the ten minutes. You'll get faster connects and a quieter security surface for the life of the machine.

Quick Comparison

Factor	Iwd	Wpa Supplicant
Connection speed	Sub-second association, optimized scanning	Noticeably slower scan/negotiate cycle
Dependencies / footprint	Kernel crypto, tiny ell lib, no OpenSSL	Bundles OpenSSL/GnuTLS, large userspace TLS
Enterprise EAP coverage	Good and growing, a few edge gaps	Encyclopedic, 20 years of fixes
Configuration & tooling	iwctl + native profiles + clean DBus	Flat conf file, wpa_cli, control sockets
Ubiquity / driver support	Needs modern kernel; not default everywhere	Runs everywhere, default on most distros

The Verdict

Use Iwd if: You run a modern Linux system (systemd era), want fast association, low memory, and a clean DBus API — iwd connects in well under a second and needs no OpenSSL.

Use Wpa Supplicant if: You need WPA3-Enterprise edge cases, exotic EAP methods, or are on hardware/distros where iwd's kernel and driver assumptions don't hold yet.

Consider: NetworkManager can drive either backend. If you're on NM already, switching the WiFi backend to iwd is a one-line config change worth trying before you assume wpa_supplicant is mandatory.

Iwd vs Wpa Supplicant: FAQ

Is Iwd or Wpa Supplicant better?

Iwd is the Nice Pick. iwd is leaner, faster to connect, has zero external crypto dependencies, and ships a sane built-in profile and DBus story. wpa_supplicant is the incumbent and works everywhere — but "works everywhere" is the only argument left in its favor, and that's not a reason to start a new system on it.

When should you use Iwd?

You run a modern Linux system (systemd era), want fast association, low memory, and a clean DBus API — iwd connects in well under a second and needs no OpenSSL.

When should you use Wpa Supplicant?

You need WPA3-Enterprise edge cases, exotic EAP methods, or are on hardware/distros where iwd's kernel and driver assumptions don't hold yet.

What's the main difference between Iwd and Wpa Supplicant?

iwd and wpa_supplicant both manage WiFi authentication on Linux. We pick the one that does it without dragging a decade of cruft behind it.

How do Iwd and Wpa Supplicant compare on connection speed?

Iwd: Sub-second association, optimized scanning. Wpa Supplicant: Noticeably slower scan/negotiate cycle. Iwd wins here.

Are there alternatives to consider beyond Iwd and Wpa Supplicant?

NetworkManager can drive either backend. If you're on NM already, switching the WiFi backend to iwd is a one-line config change worth trying before you assume wpa_supplicant is mandatory.

The Bottom Line

Iwd wins

iwd is leaner, faster to connect, has zero external crypto dependencies, and ships a sane built-in profile and DBus story. wpa_supplicant is the incumbent and works everywhere — but "works everywhere" is the only argument left in its favor, and that's not a reason to start a new system on it.

Related Comparisons