arXiv:2610.23116v1 Announce Type: new Abstract: Multi-dwelling-unit (MDU) properties increasingly deploy one community-wide SSID on which every unit or resident has its own pre-shared key, mapped to its own VLAN so that each unit is a separate network. Vendors name this capability differently (ePSK, iPSK, MPSK, DPSK, PPSK); we call it multi-PSK (mPSK). When the keys are held in an external RADIUS server or a cloud controller, the access point (AP) must ask the key server to identify a client's key. Enabling IEEE 802.11r Fast BSS Transition with WPA2-PSK (FT-PSK), which large properties need for roaming voice and video, breaks this exchange in three ways. First, the server must identify the key from an FT handshake whose MIC depends on the FT key hierarchy. Second, the RADIUS messages no longer fit: EAPOL-Key message 2 and the key material the AP needs both exceed the 247-octet value capacity of a RADIUS vendor-specific attribute (VSA). Third, the AP a device roams to needs a PMK-R1 for that device, and all key material must disappear when the resident leaves. We present FT-mPSK. The key server identifies the PSK, derives PMK-R0 and PMK-R1, and returns the serving AP's keys in a two-fragment Key-Bundle VSA that the AP reassembles and authenticates before decryption. It then calls one POST API on the cloud management system, which pushes PMK-R0 to the primary AP. On a roam, the target AP obtains PMK-R1 from the primary AP, located by the R0KH-ID in the FT Authentication Request, or from the key server. When the Property Management System reports a move-out or lease end, the key server issues the same POST as a delete keyed by the resident's mPSK username, and every AP purges that username's PSK, PMK, PMK-R0 and PMK-R1. We specify the external-RADIUS and cloud-controller methods, the attribute and fragment formats, the API, algorithms, size budgets, complexity, security properties and the validation plan.