### System details

Apple M1 MacBook Pro (MacBookPro17,1), Apple AGX GPU, Arch Linux ARM / Asahi, Omarchy `4.0.3rc4-2`, Quickshell `0.3.1-1`, NetworkManager `1.58.1-1`, Qt `6.11.2`, Hyprland `0.56.2`, kernel `7.1.13-3-2-ARCH`.

### What's wrong?

The network panel shows a padlock next to a saved, connected open Wi-Fi network. The network accepts connections without a password and NetworkManager correctly reports it as open.

The underlying Quickshell classification bug is confirmed and reported upstream: https://github.com/quickshell-mirror/quickshell/issues/1229. This issue tracks the visible effect in Omarchy.

### Steps to reproduce

1. Save/connect to an ordinary open infrastructure Wi-Fi network. Its NetworkManager profile has no `802-11-wireless-security` settings group.
2. Open Omarchy's network panel.
3. Observe the network in **Known Networks**, marked **Connected**, with a padlock on its right.

Expected: the open network has no credentials-required padlock.

Actual: the padlock appears despite a successful connection without a password.

The observed network initially appeared without a padlock during one attempt. Once its profile existed, the lock reappeared and remained visible even after the connection succeeded. The stable, connected state has been captured in a screenshot and independently checked against NetworkManager and Quickshell.

### Verified evidence

NetworkManager's active AP reports (SSID anonymized):

```text
IN-USE  SSID       SECURITY  WPA-FLAGS  RSN-FLAGS
*       OpenGuest  --        (none)     (none)
```

The active profile's D-Bus `GetSettings()` response contains `connection`, `802-11-wireless`, `ipv4`, `ipv6`, and `proxy`, with **no** `802-11-wireless-security` group.

A separate Quickshell process loading only `Quickshell.Networking` repeatedly reports:

```json
{"connected":true,"known":true,"security":11,"securityName":"Unknown","isOpen":false}
```

`WifiSecurityType.Open` is 10 in this build. The minimal QML probe and complete reproduction are in the upstream report.

### Cause

In Quickshell, [`securityFromSettingsMap()`](https://github.com/quickshell-mirror/quickshell/blob/41651d7dcd62a9400eb6f4f8a8580efe00901efb/src/network/nm/utils.cpp#L21) returns `Unknown` when `802-11-wireless-security` is missing, while an explicitly empty group returns `Open`. Its wireless network model prefers saved settings over the AP's security classification.

Omarchy's [`requiresCredentials()`](https://github.com/omacom/omarchy/blob/8b4eae66da2938ba9559f103b18dbf85cdf28a70/shell/plugins/panels/network/Model.js#L321) returns true for values other than `Open`/`Owe`, so Quickshell's incorrect `Unknown` value produces the lock.

A small QtCore test using the exact Quickshell 0.3.1 classifier reproduces `Unknown` for a valid open profile without the security group. Changing that case to return `Open` fixes the classification in isolation; checks for an empty security group, WPA2-PSK, OWE, and WEP retain their existing results.

The installed shell and networking configuration were left in place during verification. This report establishes the saved-profile security classification and padlock bug; it does not attribute an earlier association timeout to the same cause.