Per-unit VLAN and PSK architecture: a design walkthrough for MDU networks

Give each apartment its own VLAN when units have wired ports and the building has a few hundred doors. A 250-door BTR scheme uses about 256 of the 4,094 IEEE 802.1Q VLAN IDs. For high-churn sites such as an 800-bed PBSA, put the segmentation in each resident's unique key, with per-key policy on a handful of shared VLANs.

Should every apartment get its own VLAN?

Not always. Every resident in a build-to-rent (BTR), multi-dwelling unit (MDU) or purpose-built student accommodation (PBSA) scheme needs a private network. Their laptop, smart TV and printer should see each other, and nobody else's devices should see them. That is the at-home experience with enterprise security, and you can deliver it in two ways.

VLAN per apartment. Each unit gets its own virtual LAN (VLAN). A VLAN is a separate layer 2 broadcast domain with its own subnet and DHCP scope. A RADIUS server tells the access point which VLAN each device joins. RADIUS is the authentication protocol that checks each device and returns its network policy. Traffic between units must cross a layer 3 gateway, and your firewall blocks it there.

Policy carried by the key. Each resident gets a unique pre-shared key (PSK) on one shared SSID. Vendors call this identity PSK (iPSK), private PSK (PPSK), multi-PSK or dynamic PSK. The key identifies the resident, and the network applies the policy tied to it. Devices on the same key can talk to each other. Devices on different keys cannot, even on a shared VLAN. Purple calls this a Private Area Network (PAN): a private network bubble that travels with the key.

Both designs isolate residents properly. They differ in where the isolation is enforced and in how much configuration you maintain. The choice turns on four factors:

• wired ports in the units
• resident churn
• total segment count
• what your access points and switches support

The sections below work through each factor with unit counts for a 250-door BTR scheme and an 800-bed PBSA site.

Where per-unit VLANs and key-based policy genuinely differ

The 4,094 VLAN ceiling, and when you actually hit it

IEEE 802.1Q carries the VLAN ID in a 12-bit field. That gives 4,096 values. IDs 0 and 4,095 are reserved, which leaves 4,094 usable IDs. The ceiling applies per layer 2 domain, not per organisation, so two buildings behind a routed boundary can reuse the same IDs.

A single building rarely reaches 4,094 on resident VLANs alone. You hit the ceiling in three situations:

• A multi-block campus runs one flat layer 2 domain. Five 800-bed halls on one core need 4,000 resident VLANs before you add staff, CCTV or building management.
• You segment per bed and per port. If each bed also gets a separate wired VLAN, your count doubles.
• You add a per-unit IoT VLAN for smart locks or thermostats, which doubles the count again.

The practical ceiling usually arrives sooner. Per-VLAN spanning tree variants run one spanning tree instance per VLAN, and switch platforms cap instances well below 4,094. Wireless controllers and gateways also publish their own limits on VLANs and layer 3 interfaces. Check those three datasheet figures before you commit. The 802.1Q maximum is the wrong number to plan against.

If you outgrow the ceiling, you have two clean exits. Put a routed boundary at each building and reuse VLAN IDs inside each one. Or move to VXLAN, defined in RFC 7348, whose 24-bit segment identifier allows around 16 million segments. Multiple Spanning Tree, originally IEEE 802.1s and now part of 802.1Q, maps many VLANs onto a few instances. That removes the spanning tree constraint.

How RADIUS assigns a resident to a VLAN

RFC 3580 defines dynamic VLAN assignment. When RADIUS accepts a device, the Access-Accept message carries three attributes:

• Tunnel-Type = VLAN (13)
• Tunnel-Medium-Type = 802 (6)
• Tunnel-Private-Group-ID = the VLAN ID for that apartment

The access point or switch then places the device on that VLAN. The mapping lives in the resident's record, so their phone lands on the same VLAN in the flat, the gym or the roof terrace.

How the server identifies the device's owner depends on the authentication method:

• IEEE 802.1X (WPA2-Enterprise or WPA3-Enterprise). The resident signs in with a credential or certificate, and RADIUS looks it up directly.
• Per-key PSK. The controller or RADIUS server matches the key the device presented to the resident's record, then returns the VLAN or policy name.

Vendors implement that key lookup differently. Follow your platform's documentation for the configuration steps.

PSK wins in residential buildings for one practical reason. Smart TVs, games consoles, smart speakers and printers rarely support 802.1X, but a key works on all of them.

Check whether your platform supports per-key PSK with WPA3-Personal. Many per-key implementations launched on WPA2-Personal. SAE (Simultaneous Authentication of Equals, the WPA3-Personal handshake) changes how a key can be matched, and support varies by vendor and firmware.

When a resident moves flat or moves out, RADIUS dynamic authorisation helps. It is defined in RFC 5176, and it lets the server disconnect a session or push new policy straight away.

Broadcast domain hygiene

Every VLAN is a broadcast domain. ARP requests, DHCP discovery and multicast discovery protocols reach every device in it. Those protocols include mDNS, which AirPlay and Chromecast use, and SSDP. On WiFi, broadcast and multicast frames go out at a basic data rate. They consume airtime on every access point that carries the VLAN.

A per-unit VLAN keeps each domain to one household, roughly eight to 36 devices. Discovery works inside the flat without an mDNS gateway, and nothing leaks next door.

A shared VLAN can hold hundreds of devices from many residents, so it needs active hygiene:

• Proxy ARP or ARP suppression at the access point, so the AP answers ARP requests instead of flooding them.
• Multicast-to-unicast conversion or broadcast filtering on the resident SSID.
• An mDNS gateway scoped per key, so a resident's casting targets appear only on their own devices.
• A size limit. Our working rule is a few hundred clients per shared VLAN. Split by floor or block above that.

Some platforms enforce key-level grouping natively. Cisco Meraki's Wireless Personal Network, for example, groups devices by identity PSK and isolates groups from each other on a shared VLAN. On a Meraki estate, test fast roaming alongside it. Our guide to Cisco Meraki 802.11r adaptive vs enabled covers that behaviour.

DHCP scope design per segment

We plan for eight to 12 devices per resident. That is Purple's planning figure, and it covers:

• phones, laptops, tablets and watches
• TVs, consoles and speakers
• smart-home devices

Size each scope from the maximum occupancy of the unit, not the average.

Then add headroom for private MAC addresses. Apple and Google both randomise a device's MAC address per network by default. A new random address takes a new lease. Shorten lease times so abandoned addresses return to the pool within a day, and keep at least a third of each scope free.

Prefix	Usable addresses	Leases after gateway	Fits
/28	14	13	Not recommended: one resident at 12 devices leaves one spare
/27	30	29	One resident at 12 devices, 17 spare
/26	62	61	Three residents at 12 devices, 25 spare
/23	510	509	One floor of 25 residents at 12 devices, 209 spare

Run DHCP on the gateway, or on a central server with DHCP relay on each VLAN interface. A per-unit design needs one scope and one relay per VLAN, so a 250-door building has 250 scopes. The benefit is that an IP address identifies the flat, which speeds up fault-finding. On shared VLANs, the address no longer maps to a unit. You find the resident through RADIUS accounting, which logs the key, MAC address and session.

Factor	VLAN per apartment	Policy carried by the key
Where isolation is enforced	Layer 3 gateway and firewall	Access point or controller
Resident VLANs used	One per unit	One per floor or block
Wired ports in units	Same segment as WiFi, via port VLAN or MAC authentication	Needs a separate wired design
AirPlay and Chromecast discovery	Works inside the VLAN, no gateway	Needs an mDNS gateway scoped per key
Broadcast domain size	One household, up to about 36 devices	Up to a few hundred devices
DHCP scopes	One per unit	One per shared VLAN
Hardware dependency	Dynamic VLAN assignment (RFC 3580)	Per-key PSK plus per-key isolation
Best fit	BTR and MDU with wired ports and long tenancies	PBSA, aparthotels, multi-block campuses

When a VLAN per apartment is the right call

Choose a VLAN per apartment when most of these hold:

• Units have wired ports. One VLAN carries the resident's wired TV, smart hub and WiFi devices, so casting works across both.
• Tenancies run for months or years. The VLAN-to-unit map rarely changes.
• Segment count stays well under your platform limits. Count spanning tree instances, controller VLANs and gateway interfaces.
• Your security team wants isolation at layer 3, with firewall logs per segment.
• Support needs the IP address to identify the unit without a RADIUS lookup.

Worked scenario: a 250-door BTR scheme

Situation. A 250-apartment build-to-rent block, ranging from studios to two-beds, with a maximum of three residents per unit. Every apartment has wired ports for a TV and a smart-home hub. The amenity floor has a gym, a co-working lounge and a roof terrace. Staff, CCTV, building management and lounge visitors each need their own network.

What was done.

• One VLAN per apartment: 250 resident VLANs.
• Six infrastructure VLANs: management, staff, CCTV, building management, IoT and a visitor Guest WiFi network for the amenity spaces. That makes 256 VLAN IDs in total.
• A uniform /26 per apartment. Three residents at 12 devices is 36 devices, which leaves 25 leases spare. One template covers every unit.
• One /18 for all resident scopes. The 250 /26 scopes fit inside a single /18 of RFC 1918 private space, with six /26 blocks left over.
• Wired and wireless on one segment. RADIUS maps each resident's key to their apartment VLAN, and the flat's wired ports sit on the same VLAN.
• Multiple Spanning Tree maps the 256 VLANs onto a small number of instances.

Outcome (design figures).

• 256 of 4,094 VLAN IDs used, about 6%.
• 256 DHCP scopes and 256 layer 3 interfaces, managed from one firewall rule template.
• Every resident address identifies its flat.
• A second 250-door phase would take the total to 506 VLANs, still about 12% of the ID space.

When policy-based segmentation is the right call

Choose policy carried by the key when most of these hold:

• Churn is high. Annual intakes or nightly stays make VLAN-to-unit maintenance a recurring job.
• Residents roam the whole building, including study rooms, cafés and gyms.
• Per-bed privacy would push VLAN counts into the hundreds or thousands.
• Rooms have no wired ports, or the ports serve building systems only.
• Your access points support per-key PSK, per-key isolation and scoped mDNS.

Worked scenario: an 800-bed university hall

Situation. A university operates an 800-bed hall across four blocks of eight floors, with 25 beds per floor. Students live in cluster flats of five to eight bedrooms around a shared kitchen. Flatmates expect privacy from each other, so segmentation is per bed. Most beds turn over at the start of each academic year.

Option A: a VLAN per bed.

• 800 resident VLANs.
• A /27 per bed holds 12 devices with 17 spare, which totals 25,600 addresses and needs a /17.
• 800 DHCP scopes and 800 gateway interfaces.
• Every VLAN trunked to every access point a student might use, which means the whole site.

Option B: policy carried by the key.

• Each student receives a unique key at check-in.
• One shared VLAN per floor gives 32 resident VLANs.
• Each /23 offers 509 leases against 300 devices (25 students at 12 devices), leaving 209 spare.
• The 32 /23 scopes fit in a /18.
• Per-key isolation runs on the access points, with an mDNS gateway scoped per key. Proxy ARP and multicast-to-unicast run on the SSID.

What was done. Option B. The key maps each student to their home-floor VLAN. A student who walks to the café keeps the same address and policy. All 32 VLANs are trunked to every access point, a far lighter load than 800.

Outcome (design figures).

• 32 resident VLANs instead of 800, a 96% reduction.
• 32 DHCP scopes instead of 800.
• Half the address space: a /18 instead of a /17.
• Broadcast domains of about 300 devices each, within our working rule.
• The annual turnover means revoking and reissuing keys only, with no VLAN, scope or trunk changes.

Worked scenario: a 120-unit aparthotel

Situation. A 120-apartment aparthotel across six floors, 20 apartments per floor. Stays run from one to 14 nights. Guests bring streaming sticks and expect to cast from their phones. The front desk issues WiFi access at check-in.

What was done.

• Each stay receives its own key at check-in, mapped to a per-apartment policy group.
• Short stays carry fewer devices, so the plan uses eight devices per guest and two guests per apartment. That is 320 devices per floor.
• Each floor gets one /23 VLAN, which leaves 189 leases spare.
• The design revokes each key at checkout.

Outcome (design figures).

• Six resident VLANs instead of 120, a 95% reduction.
• Six DHCP scopes.
• No VLAN changes between stays.
• Casting works inside each stay through the per-key mDNS scope.

For the wider guest network picture, see our Hotels page.

What each design costs to run

Neither design changes your access point count. That is set by device density and coverage. The running cost is the number of objects you configure, change and troubleshoot.

Item to maintain	250-door BTR, VLAN per apartment	800-bed PBSA, VLAN per bed	800-bed PBSA, policy by key
Resident VLANs	250	800	32
DHCP scopes	250	800	32
Layer 3 gateway interfaces	250	800	32
Private address space	/18	/17	/18
VLANs trunked to every AP (with 6 infrastructure)	256	806	38
Isolation enforced at	Gateway firewall	Gateway firewall	Access point or controller
Change at resident turnover	Reissue key	Reissue key	Reissue key

With a VLAN per unit, the cost is change management. Every new block adds VLANs, scopes, gateway interfaces, firewall entries and trunk changes on every switch in the path. Template and automate that work, or it drifts.

With policy carried by the key, the cost moves elsewhere. You depend on per-key features in your access point firmware and licence. Troubleshooting also shifts from IP addresses to RADIUS accounting logs, so train your support team to read them.

Purple Multi-Tenant WiFi runs as a cloud overlay on the hardware you already own. Our cloud RADIUS issues each resident a key and returns their VLAN or policy. Joiners, movers and leavers are handled from a single pane of glass. Purple is hardware-agnostic across:

• Cisco Meraki
• HPE Aruba
• Ruckus
• Juniper Mist
• Ubiquiti UniFi
• Cambium
• Extreme
• Fortinet

Purple runs in 80,000+ live venues and handled 440 million logins in 2024, according to Purple's own data. Purple is ISO 27001 certified and GDPR compliant. For why segmentation rarely needs new access points, read Why your next WiFi upgrade doesn't need new hardware.

How to decide for your estate

Your situation	Recommendation	Why
Up to about 500 units, wired ports, tenancies of 12 months or more	VLAN per apartment	Wired and WiFi share one segment; ID use stays near 12%
PBSA with per-bed privacy and annual turnover	Policy by key, one shared VLAN per floor	96% fewer VLANs at 800 beds; no re-plan at each intake
Aparthotel or serviced apartments with stays of days	Policy by key	Keys follow the stay; the VLAN map never changes
Multi-block campus on one layer 2 core, over 3,000 segments	Routed boundary per building, or VXLAN, then either model	4,094 IDs per layer 2 domain
Wired-port apartments and cluster flats on one site	Hybrid: VLAN per apartment where ports exist, policy by key elsewhere	Each model where its strengths apply
Access points without per-key isolation	VLAN per apartment, or plan a firmware or AP upgrade	Isolation has to be enforced somewhere

Work through five steps before you commit to a design.

1. Count your segments. Count units or beds, then add infrastructure VLANs and any wired or IoT multiplier. Compare the total with your spanning tree, controller and gateway limits, not with 4,094.
2. Size scopes from maximum occupancy. Multiply residents by 12 devices, then keep at least a third of each scope free.
3. Confirm per-key features with your vendor. Check per-key PSK, per-key VLAN assignment, per-key isolation, scoped mDNS and WPA3-Personal support on your firmware.
4. Survey for density. Eight to 12 devices per resident changes access point counts. Our WiFi Site Surveys guide covers the planning.
5. Test roaming between the flat and amenity spaces. If residents move between floors, tune 802.11r and 802.11k. See 802.11r and 802.11k on Android for vendor-specific settings.

Frequently asked questions

Does Purple Multi-Tenant WiFi work with the access points already in my building?

Yes. Purple is hardware-agnostic and runs as a cloud overlay on Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet. You keep your access points and switches. Purple provides the cloud RADIUS and identity layer that issues each resident a key and returns their VLAN or policy. If you choose policy-based segmentation, confirm that your firmware supports per-key PSK and per-key isolation.

Can we move from one shared building password to per-unit keys without replacing hardware?

Yes, if your access points support per-key PSK or dynamic VLAN assignment. Purple layers on top of existing infrastructure, so no rip and replace is required. Run the new resident SSID alongside the old one, then move residents across unit by unit. Retire the shared password once the last resident has moved. Plan your VLAN or policy map and DHCP scopes before the first resident switches.

How many VLANs can one MDU building support?

Up to 4,094 per layer 2 domain, the limit set by the 12-bit VLAN ID in IEEE 802.1Q. In practice, spanning tree instance limits, controller VLAN limits and gateway interface counts usually bite first. A 250-door BTR scheme with six infrastructure VLANs uses 256 IDs. Campuses that need more should put a routed boundary at each building or move to VXLAN.

Is key-based segmentation as secure as a VLAN per apartment?

Yes, provided your platform enforces isolation between keys at the access point or controller. The difference is the enforcement point. A per-unit VLAN blocks cross-unit traffic at the layer 3 gateway. Key-based policy blocks it before traffic leaves the access point. Test this from a resident device. Confirm you cannot reach another resident's devices or discover their casting targets.

Will smart TVs, consoles and IoT devices work on a segmented resident network?

Yes. Both designs use a pre-shared key, which works on devices without 802.1X support, such as smart TVs, games consoles and smart speakers. Each resident's devices share their own VLAN or key group, so casting and printing work inside the home. On shared VLANs, add an mDNS gateway scoped per key so device discovery stays private to each resident.

How does Purple handle resident data under GDPR?

Purple is ISO 27001 certified and GDPR compliant. Each key links to a resident record in the cloud RADIUS layer. RADIUS accounting logs which key and device held each session, which supports fault-finding and access requests. When a resident leaves, you revoke their key, and the joiners, movers and leavers process closes their network access from a single pane of glass.

What happens to a resident's devices when they move out?

They lose access when you revoke the key or credential. Where your access points support it, RADIUS dynamic authorisation (RFC 5176) disconnects active sessions straight away. With a VLAN per apartment, the VLAN and DHCP scope stay in place for the next resident. With key-based policy, there is nothing to re-plan: you issue the new resident a new key.