802-11-wireless-security.key-mgmt: property is missing is what NetworkManager 1.52 prints when you try to connect an edge box to a property's WiFi the old way. Here is the one-liner that works, and why your appliance should not care if it fails.
Every top-ranked answer to this error is a distro forum thread for a laptop. This page is for a different reader: an installer crouched next to a hybrid DVR in a leasing-office closet, with a Cyrano edge unit half-installed, 90 seconds before the property manager needs to lock up. The fix is two commands. The deeper point is that your edge appliance should keep doing its job whether you ever run them or not.
See an edge install that survives a broken WiFiWhat the error means, in one paragraph
A NetworkManager connection profile has a section called 802-11-wireless-security. That section has a field called key-mgmt that selects the authentication regime: no security, WPA-Personal, WPA-Enterprise, WPA3-Personal, and so on. Before NetworkManager 1.52 the daemon would infer the value from the presence of a password. Starting at 1.52, that inference was removed. The validator now rejects any profile that supplies a psk without an explicit key-mgmt. The word property in the error is NetworkManager-speak for that field, not anything about a multifamily building.
That is all it is. A missing field on a profile the daemon now refuses to guess about. The fixes are either to let the daemon prompt you interactively (which supplies a key-mgmt value on your behalf), or to supply the value yourself.
The old command, and the two replacements
Side by side. Left column is what used to work. Right column is either of two ways to make it work again.
nmcli on NetworkManager 1.48 vs 1.52
# Fills in key-mgmt on your behalf.
nmcli device wifi connect "PropertyWiFi" \
password "hunter2"
# Also worked:
nmcli connection add type wifi \
ifname wlan0 \
con-name propwifi \
ssid "PropertyWiFi" \
wifi-sec.psk "hunter2"
nmcli connection up propwifiWhere the error comes from, in one diagram
The daemon receives a candidate profile, runs the validator on it, and fails on the missing key-mgmt. Everything downstream never runs. That is why you see a fast error rather than a timeout.
nmcli connect, with and without key-mgmt
The exact field fix, as a terminal session
From a cold shell on a Cyrano unit at a property, this is the full session that takes you from the broken one-liner to an authenticated, routed, alert-draining state.
A keyfile you can pre-bake and stop seeing this error forever
If you know the SSID before you arrive, write the keyfile into the image. NetworkManager autoloads any file in /etc/NetworkManager/system-connections that is mode 0600 and owned by root. Because key-mgmt is declared, the validator never has to guess.
After writing the file, run chmod 600 on it and nmcli connection reload. It will come up on next boot without the installer ever touching nmcli.
Why this matters on an edge appliance, in numbers
The numbers that matter are not the ones about nmcli. They are the ones about what happened on the HDMI feed while you were debugging it.
The 90-second field fix, step by step
From broken one-liner to alert-draining, in one visit
1. Read the exact error, not the stack trace around it
The first line that starts with 'Error: 802-11-wireless-security.key-mgmt' is the whole story. Ignore anything the shell printed before it. You have a validation failure, not a backend failure.
2. Confirm the NetworkManager version
Run nmcli --version. If it is 1.52.0 or later, the inference change is why you are here. If it is 1.48.x or earlier, something else is wrong and you should go looking at the device and psk instead of at the key-mgmt field.
3. Find the interface name
Run nmcli device status. The wifi interface is usually wlan0 on embedded Linux and wlp* on desktop distros. Write the name down, it goes into the next command.
4. Run the explicit add, not the one-liner
nmcli connection add type wifi ifname <iface> con-name propwifi ssid "<SSID>" 802-11-wireless-security.key-mgmt wpa-psk 802-11-wireless-security.psk "<psk>". The profile is saved regardless of whether the radio can reach the AP right now.
5. Bring it up
nmcli connection up propwifi. If this fails, the profile is fine and the problem is radio-side (psk wrong, 5GHz-only AP, MAC filter). If it succeeds, you are done with WiFi.
6. Verify by watching the Cyrano agent, not nmcli
journalctl -u cyrano-agent -f. Watch for queue.drain and uplink.up. Those lines mean the appliance is using the uplink. If you never see them, the unit is either still on Ethernet (fine) or still offline (also fine, inference continues).
Four things about Cyrano that make this error survivable
None of this is theoretical. Each of the four is the reason an installer can walk out of a property with a working deployment even when WiFi never comes up.
Inference is local, not cloud
Every classifier (person, vehicle, loitering, tailgating, package, restricted-area entry) runs on the silicon inside the unit. No cloud round-trip is in the critical path, so losing the uplink does not stop detection.
Alert queue on disk
Alerts accumulate in a local queue when the uplink is down. The queue drains to WhatsApp and the dashboard when any uplink comes up.
Ethernet first, WiFi second
The provisioning order favors wired Ethernet. If the property has a patch cable free, the unit is online before nmcli is ever invoked.
Idempotent connection add
The fix command can be baked into a provisioning script and re-run at any time without tearing down the existing profile. That matters when the SSID or psk changes later and the installer is not on-site.
HDMI path is independent of IP path
The unit sits on the HDMI cable between the DVR and the monitor. The video signal reaches the unit through physical cabling that has nothing to do with WiFi. nmcli can be broken all day and the inference pipeline stays up.
The anchor fact: the two commands that replace the old one-liner
If you read nothing else on this page, read these two. They are the entire fix. One is interactive, one is scriptable. Either one writes a profile the NetworkManager 1.52+ validator accepts, because both produce a non-missing key-mgmt value.
nmcli --ask device wifi connect "PropertyWiFi"
nmcli connection add type wifi ifname wlan0 \ con-name propwifi ssid "PropertyWiFi" \ 802-11-wireless-security.key-mgmt wpa-psk \ 802-11-wireless-security.psk "hunter2" nmcli connection up propwifi
Both commands populate the key-mgmt field with wpa-psk. Substitute sae for WPA3-Personal, none for open networks, wpa-eap for WPA2-Enterprise.
What a good install session looks like, checklist
If the WiFi goes sideways, these still have to hold
- HDMI signal lock achieved within one second of plug-in
- Tile layout detected (2x2, 3x3, 4x4, 5x5, or custom) on the composite frame
- Per-tile inference ticking at display refresh, 30 fps
- Ethernet uplink preferred over WiFi, brought up first
- nmcli command to add a wifi profile includes 802-11-wireless-security.key-mgmt
- Alert queue drains on first successful uplink, Ethernet or WiFi
- No video leaves the property, only thumbnails plus metadata
- Unit keeps running inference if WiFi is never fixed
Why the SERP's laptop advice is not quite right for an appliance
Walk through the first five search results for this error. Arch Linux Forums, Manjaro Linux Forum, a balena-cli GitHub issue, a Raspberry Pi Forums thread, the NetworkManager 1.52 reference manual. Each is a fine answer for its audience, a laptop user or a hobbyist single-board computer, where the fix is a keyboard away and the outcome matters only to one machine.
An edge appliance has a different shape. The installer is almost never the end user. The machine may live in a closet behind a locked door for months. The only thing the end buyer cares about is that the inference pipeline is up. So the useful framing of this error on an appliance is not just "here is the nmcli incantation," it is "here is the nmcli incantation, and here is what your appliance does while you are typing it or after you give up and leave."
On Cyrano the answer to the second half is: inference keeps running, alerts queue on disk, and the queue drains on any later uplink. That is the part the forum threads cannot tell you, because the forum threads are about the machine itself, not about what the machine is supposed to be doing for its owner.
The top-ranked sources for this error, all aimed at a laptop user, none at a fielded edge appliance
Want to watch an install that survives a broken WiFi?
We will walk through a real deployment where nmcli threw this error, the installer ran the explicit connection add, and the alert queue drained on camera. You will see what happens on the HDMI path in parallel.
Book a 15-minute demo →Frequently asked questions
What does 'Error: 802-11-wireless-security.key-mgmt: property is missing' actually mean?
It means nmcli tried to save a new wifi connection profile that has a password (a psk) but no key-mgmt value. Older NetworkManager inferred the value (wpa-psk for a password-protected network, none for open) from context. Starting around NetworkManager 1.52 that inference was removed, so the profile is rejected at validation time and no connection gets created. The word 'property' in the error is the NetworkManager term for a setting field inside a profile, not a multifamily building. Two things fix it: run nmcli with --ask so the daemon prompts for the password interactively and fills in the right key-mgmt, or add the profile explicitly with 802-11-wireless-security.key-mgmt wpa-psk set.
The one-liner 'nmcli device wifi connect SSID password pass' used to work. Why does it fail now?
Because the one-liner delegates profile construction to the daemon, and on NetworkManager 1.52 and later, the daemon no longer fills in key-mgmt on your behalf when it sees only a psk. Arch, Manjaro, Fedora, and Raspberry Pi OS ship rolling or semi-rolling builds of NetworkManager and got this change first. Debian 12 and Ubuntu 22.04 still ship 1.42 or 1.44 and keep working. If your edge device runs on a recent rolling distro, the one-liner is silently broken. The workaround is to either invoke nmcli --ask (which lets the daemon prompt for the password in a context where it does set key-mgmt correctly) or to build the connection profile yourself with nmcli connection add and set 802-11-wireless-security.key-mgmt wpa-psk explicitly.
I am standing in a leasing-office closet. Give me the exact nmcli command that works today.
Either of these. Interactive: nmcli --ask device wifi connect "PropertyWiFi". Explicit profile: nmcli connection add type wifi ifname wlan0 con-name propwifi ssid "PropertyWiFi" 802-11-wireless-security.key-mgmt wpa-psk 802-11-wireless-security.psk "hunter2" followed by nmcli connection up propwifi. Replace wlan0 with the interface name from nmcli device status. Replace the SSID and psk with the property's values. The explicit form is idempotent, so you can script it into your provisioning playbook and re-run it without tearing down the profile.
Does this error also hit open networks or enterprise (WPA2-Enterprise / 802.1X) networks?
Yes, in different forms. For open networks, set 802-11-wireless-security.key-mgmt none. For WPA3-Personal, use sae. For enterprise, you set key-mgmt to wpa-eap and then have to provide 802-1x.eap, 802-1x.identity, 802-1x.password, and often 802-1x.ca-cert. The 'property is missing' message is the daemon telling you it cannot guess which of those regimes you want. Pick one. A multifamily property's staff network is almost always wpa-psk (WPA2-Personal).
What if I do not have time to fix it on-site? Can I leave the Cyrano unit on Ethernet and walk out?
Yes, and that is the design. The edge unit runs inference entirely on-device, so Ethernet or no uplink at all is fine for inference itself. Alerts queue on disk and drain when any uplink comes up, whether that is the Ethernet cable, a later WiFi fix, or a 4G failover dongle. The 'key-mgmt: property is missing' error becomes a non-blocking issue. Do the install in 2 minutes, get the HDMI feed locked and tile layout detected, bring up the Ethernet if one is available, and come back for the WiFi. If you never come back, the unit still does its job on Ethernet.
I got the profile created but it still will not connect. How do I tell which side is failing?
Run journalctl -u NetworkManager -f in a second terminal, then nmcli connection up propwifi. The log lines will tell you whether the radio associates (you get an Authenticated / 4-way handshake line), whether the psk is wrong (you get handshake timeout or mic failure), or whether DHCP is the problem (association succeeds but the lease never arrives). If the association fails, your key-mgmt is right but the password or the pairwise cipher is wrong. If DHCP fails, NetworkManager and the AP agree, the property's DHCP server or its client-count cap does not. That last case is common on older multifamily routers.
Does Cyrano ship with iwd or wpa_supplicant as the wifi backend?
wpa_supplicant, which is NetworkManager's default. The key-mgmt error is a NetworkManager validation error, not a backend-specific error, so it appears on either wpa_supplicant or iwd. Switching backends does not help. What helps is either using --ask to let the daemon populate key-mgmt, or declaring 802-11-wireless-security.key-mgmt in the profile.
Can I pre-bake a wifi profile into the Cyrano image so the installer never sees nmcli at all?
Yes, for sites where you know the SSID in advance. Drop a keyfile at /etc/NetworkManager/system-connections/propwifi.nmconnection with permissions 600 owned by root. The file contains [connection] id, type=wifi, and uuid lines; a [wifi] ssid line; and a [wifi-security] key-mgmt=wpa-psk and psk line. NetworkManager autoloads the file on boot. Because key-mgmt is declared, you never hit the 'property is missing' error. For sites where you learn the SSID on arrival, a captive-portal hotspot on the unit lets the installer enter credentials from their phone, and the provisioning daemon on the unit writes the keyfile with key-mgmt already set.
What does the full 90-second field fix look like end to end?
t=0 plug HDMI, Ethernet, and power. t=1s HDMI signal locks and layout detection starts. t=5s per-tile inference is live on the composite frame. t=10s you notice WiFi did not come up, run nmcli device status, see wlan0 is disconnected. t=20s you run nmcli --ask device wifi connect 'PropertyWiFi', type the psk when prompted, the daemon writes the profile with key-mgmt=wpa-psk and the connection goes up. t=35s ip addr shows a lease on wlan0. t=40s journalctl confirms the alert queue has flushed. t=45s you run a curl against the unit's health endpoint from your phone on the same WiFi, see the HDMI lock state and tile count, and leave. If the WiFi negotiation fails for any reason, you leave on Ethernet alone. Alerts keep flowing.
Where in the NetworkManager docs is key-mgmt actually defined?
In the 802-11-wireless-security settings section of the NetworkManager reference manual. The 1.52 reference lists key-mgmt as the selector between none (unencrypted), ieee8021x (dynamic WEP / LEAP, legacy), wpa-none (IBSS ad hoc, legacy), wpa-psk (WPA-Personal), wpa-eap (WPA-Enterprise), sae (WPA3-Personal), owe (OWE for open networks), and wpa-eap-suite-b-192 (Suite B). Reading that page is the fastest way to pick the right value for a given property's AP configuration. Everything else (psk, proto, pairwise, group) is constrained by key-mgmt.
Related guides
What Is Edge AI? The Definition the Generic Articles Miss
Why the edge in physical security is the HDMI cable between the DVR and the unwatched wall monitor, and what changes when you accept that coordinate.
Frigate NVR Config Optimization for Real-Time Alerts
Network, storage, and detector settings that make alerts land in seconds instead of minutes on a self-hosted NVR.
Local NVR Camera Search and Footage Management
How to search and pull footage from an on-prem NVR when the property's uplink is flaky and the cloud option is off the table.
Comments (••)
Leave a comment to see what others are saying.Public and anonymous. No signup.