Skip to content

xPSK network: things, communities and concessionsAuthentication

PPSK for retail store devices: a deployment checklist for tills, scanners and CCTV on Cisco Meraki and Juniper Mist

You will be able to give every till, scanner, printer, signage player and wireless camera its own WiFi key on one SSID, mapped to its own VLAN and policy. You can choose where keys live on Cisco Meraki, Juniper Mist or a mixed estate. You can then run a pilot, test isolation and revoke one lost device without touching...

14 min read

Private pre-shared keys (PPSK) give every till, scanner, printer and screen its own WiFi key on one SSID. Each key maps to a VLAN (virtual LAN), policy and bandwidth cap, so tills stay apart from signage and CCTV. Bind keys to MAC addresses and revoke one lost device's key. Cisco Meraki calls it Identity PSK; Juniper Mist calls it Multi PSK.

What does PPSK actually do for retail store devices?

Most store estates build their device WiFi by accident. Scanners join the staff SSID. Signage players join whatever network the installer could see. A wireless camera ends up on the guest network. Everything shares one password that has not changed since the store opened.

PPSK fixes this without asking the device to do anything new. The device still sees one SSID and enters one WPA2-Personal passphrase. The change sits on the network side. Every device gets a different passphrase. The access point matches each passphrase to an identity, either locally or by asking a RADIUS server. It then applies the VLAN, firewall rules and bandwidth limit attached to that identity. RADIUS is the protocol an access point uses to ask a central server who a device is and what it may reach.

Three consequences matter in a store:

  • Separation by identity. A till and a signage player on the same SSID land on different VLANs, with different firewall rules.
  • Containment. Under IEEE 802.11i, each device derives its session keys from its own passphrase. Anyone holding a shared passphrase who captures a handshake can derive another device's session keys. With PPSK, a leaked signage key cannot decrypt till traffic.
  • Revocation in one place. Delete one key and one device loses access. Nothing else in the store changes.

Where PPSK sits among your three networks

Purple Access runs three networks on one platform, and identity sets the VLAN on each. The open network serves shoppers through a captive portal, covered in our Captive portals guide. The secure network serves staff with IEEE 802.1X and EAP-TLS. 802.1X is the standard for authenticating each device before it joins. EAP-TLS is the method that uses a certificate on the device. Staff can also sign in with Microsoft Entra ID, Okta or Google Workspace, as shown in Okta WiFi Authentication: Setup Steps, Options and Fixes.

Certificates stay the default for people. The xPSK network covers everything that cannot hold one: tills, handheld scanners, receipt printers, signage players and wireless CCTV. We use the same model for residents in apartment buildings, explained in Multifamily WiFi: how isolation, xPSK and billing work. For the full security model, see our WiFi security guide.

PPSK compared with the alternatives

Method What the device holds Revoking one device Per-device VLAN and policy Extra infrastructure Suits
Shared PSK One passphrase shared by every device Re-key every device on the SSID No, one VLAN per SSID None Nothing that touches payments
PPSK (Meraki Identity PSK, Mist Multi PSK) Its own passphrase, optionally bound to its MAC Delete one key Yes, per key Meraki: RADIUS for MAC binding. Mist: none with Cloud PSK Tills, scanners, printers, signage, CCTV
IEEE 802.1X with EAP-TLS A client certificate Revoke one certificate Yes, per identity RADIUS server and public key infrastructure (PKI) Staff laptops and phones under MDM
MAC authentication bypass Nothing: the MAC address is the identity Remove one MAC address Yes, per MAC address RADIUS server Wired devices that support nothing else

MDM means mobile device management, the system that pushes settings to company-owned phones, scanners and laptops.

What do you need before you deploy PPSK in your stores?

Most of the work happens before you create a single key. Have these in place first:

  • A device inventory per store. Record device class, make, model, MAC address, whether the MAC is fixed, supported security modes and radio bands.
  • A segment plan. Agree one VLAN per device class with whoever owns payments, CCTV and signage contracts.
  • VLAN trunking to every access point. Each AP uplink port must carry every segment VLAN, or devices associate and then get no IP address.
  • Firewall rules per segment. Write down what each segment may reach before you configure anything.
  • Console access. You need organisation-level admin rights in Meraki Dashboard or the Juniper Mist portal.
  • A decision on where keys live. Keys can sit on the SSID itself, on a RADIUS server, or in a cloud key service. The table below maps your estate to a choice.
  • MDM control of Android scanners. You will need it to fix the MAC address per network and push keys remotely.
  • An owner for the key register. Devices have joiners, movers and leavers just like staff. Someone must record each key issued and each key revoked.
Your estate Where keys should live MAC binding Why
Cisco Meraki only, one key per device class Identity PSK without RADIUS, keys stored on the SSID Not available Fastest start, but a leaked key works on any device
Cisco Meraki, one key per device Identity PSK with RADIUS, pointing at a cloud RADIUS service Yes, lookup by MAC address Each key only works for the device it was issued to
Juniper Mist only Mist Cloud PSK Yes, with single-use keys Native to the Mist cloud, with per-key VLAN, role and expiry
Mixed estate: Meraki plus HPE Aruba, Ruckus, Mist or Ubiquiti UniFi Purple Access xPSK as cloud RADIUS Yes One key register across every vendor, no rip and replace

How do you set up PPSK on Cisco Meraki and Juniper Mist?

Step 1: design the key-to-segment map

Design the segments before you touch either console. This map keeps payment terminal WiFi security separate from everything that does not need to reach payments.

Device class Segment May reach Bandwidth policy Key scope
Payment terminals and tills Payments Payment processor and till server only Uncapped, highest priority One per device, MAC-bound
Handheld scanners Store operations Stock, ordering and handheld management systems Per-device cap One per device, MAC-bound
Receipt and label printers Store operations Till and print servers Low per-device cap One per device, MAC-bound
Digital signage players Signage Content management system and update servers Per-device cap One per device, MAC-bound
Wireless CCTV cameras CCTV Network video recorder only Reserved headroom at camera bitrate One per device, MAC-bound

Keep the number of segments small. Five segments per store is enough for most estates, and every extra VLAN must be trunked to every AP.

Step 2: Cisco Meraki and Identity PSK

Meraki applies per-key policy through group policies, so build those first. In Meraki Dashboard, create one group policy per segment. Each policy sets the VLAN tag, the bandwidth limit and the Layer 3 and Layer 7 firewall rules for that segment.

Next, open the access control settings for your device SSID. Meraki offers two Identity PSK modes:

  • Identity PSK without RADIUS. You enter keys directly on the SSID and map each key to a group policy. No MAC binding is available, so any device that learns a key gets that key's policy.
  • Identity PSK with RADIUS. The access point sends the device MAC address to your RADIUS server. The server returns the passphrase and group policy for that MAC address. A key only works for the device it was issued to.

For tills and any device on the payments segment, use the RADIUS mode. Cisco's documentation pages "IPSK without RADIUS" and "IPSK with RADIUS Authentication" give the exact steps for each mode.

Step 3: Juniper Mist and Multi PSK

In the Juniper Mist portal, set your device WLAN to use multiple passphrases. Mist gives you three key sources: keys stored locally on the WLAN, Cloud PSKs held at organisation level, or keys returned by a RADIUS server.

For a store estate, Cloud PSK is the native choice. Each Cloud PSK carries its own VLAN, role and expiry date. Set store devices to single-use, which binds the key to the first MAC address that joins with it. Then use each key's role in your WxLAN policies to control what that segment may reach. Apply rate limits to cap signage and scanner bandwidth. Juniper's Multi PSK documentation covers the WLAN settings and Cloud PSK fields in full.

Step 4: Purple Access as one key register across vendors

Most retail estates run more than one hardware vendor after acquisitions and refits. Purple Access runs the xPSK network as cloud RADIUS, so one key register serves every store. Meraki SSIDs point Identity PSK with RADIUS at Purple. Mist WLANs use RADIUS as the key source. Purple returns the per-device key, VLAN and policy for each MAC address.

The same model runs on Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet. You keep your access points and switches. Purple's support article for your vendor lists the exact RADIUS settings.

The store rollout checklist

  1. Pick one pilot store that contains every device class you run.
  2. Export that store's device inventory, with a verified MAC address for each device.
  3. Trunk every segment VLAN to every AP uplink port before cutover day.
  4. Create the segment policies: group policies on Meraki, roles and WxLAN policies on Mist.
  5. Create one key per device and record it in the key register.
  6. Push a fixed-MAC setting for the device SSID to Android scanners through MDM.
  7. Broadcast the device SSID alongside the existing staff SSID.
  8. Move devices class by class: signage first, then printers and scanners, then tills outside trading hours.
  9. Run every test in the next section before you move the next class.
  10. Change the old shared staff password one final time, so no device can fall back to it.
  11. Write the revocation runbook: device lost, key revoked, replacement issued with a new key.
  12. Roll out in waves of stores, reusing the pilot policies, and keep test results as evidence.

How do you check PPSK works in each store?

Test every device class, not one device. A passed test on a scanner tells you nothing about a printer on a different VLAN.

  • Right segment. Check the client list in Meraki Dashboard or Mist client insights. Each device should show the expected VLAN and an IP address from that segment's subnet.
  • Isolation. From a test device on the signage segment, try to reach the till server and the video recorder. Both attempts should fail.
  • MAC binding. Enter a scanner's key on a test phone. The phone should be rejected.
  • Revocation. Revoke a test key and confirm the device cannot rejoin. If the existing session persists, disconnect the client from the console. Every other device in the store should stay connected.
  • Bandwidth. Run a throughput test from a signage player and confirm the cap holds. Our guide to Bandwidth Usage Measurement: Methods, KPIs and Setup covers the method.
  • Roaming. Walk a scanner from the stockroom to the far end of the shop floor. The scanning app should stay connected.

Keep the outputs. Your key register, segment policies, revocation logs and isolation test results provide evidence for PCI DSS v4.0. Requirement 1 covers network security controls between segments. Requirement 2.3 covers wireless environments, including changing default keys. Rogue access point checks under requirement 11.2.1 remain a separate task.

What goes wrong with PPSK, and how do you fix it?

Symptom Likely cause Fix
Device associates but gets no IP address Segment VLAN not trunked to the AP's switch port Tag every segment VLAN on every AP uplink port
Scanner rejected after an OS update MAC randomisation switched on; Android 10 and later randomise per network by default Set the device SSID profile to use the device MAC through MDM
One key works on two devices Key not bound to a MAC address (Meraki without RADIUS, Mist multi-use) Move to Identity PSK with RADIUS or Mist single-use keys
Older printer cannot join Device supports 2.4 GHz and WPA2-Personal only Keep 2.4 GHz and WPA2-Personal enabled on the device SSID
Scanner drops between aisles 802.11r fast roaming incompatible with a legacy client Test with fast transition disabled on the device SSID
Tills slow during a signage content push Signage policy has no bandwidth cap Apply a per-device cap to the signage segment
Lost device still online after key deletion Existing session persists until reauthentication Disconnect the client in the console after revoking

Two problems deserve more than a table row.

The first is the key that becomes a second shared password. A technician writes a scanner key on a sticker, and six devices end up using it. MAC binding stops this. Without binding, a per-device key is only a per-device key by convention.

The second is WPA3. Many per-device key implementations rely on WPA2-Personal, and many tills and printers support nothing newer. Check the Cisco Meraki and Juniper Mist documentation for WPA3 support on your firmware before you design around it.

Two worked scenarios: a fashion chain and a stadium

Retail: a 150-store fashion chain on Cisco Meraki

Situation. Consider a 150-store chain with six tills, eight scanners, two printers and four signage players per store. All 20 devices share the staff SSID and one password. That makes 3,000 devices on one key across the estate. PCI DSS requirement 2.3.2 asks you to change wireless keys when someone who knows them leaves. Every store manager knows this password, so every manager leaving should trigger 3,000 re-keys. In practice, it never happens.

What was done. The chain adds a device SSID using Identity PSK with RADIUS, with Purple Access holding the key register. Four group policies separate payments, store operations, signage and printers. MDM pushes keys to scanners, so store staff never see a device key.

Outcome. A stolen scanner now means one key revoked and zero other devices touched, instead of 20 in that store. A manager leaving no longer triggers a rotation, because managers never hold device keys. The payments segment shrinks from 20 devices per store on a flat network to six tills. PCI SSC guidance says segmentation can reduce the systems in scope, subject to your assessor's validation.

Events: a stadium on Juniper Mist

Situation. Consider a stadium with 40 permanent concession tills and 120 signage screens. A ticketing contractor brings 25 handheld scanners to every event. The contractor has always been given the staff password, and it has never changed.

What was done. The stadium moves to Mist Cloud PSKs. Tills get single-use keys on the payments VLAN. Signage keys carry a role with a rate limit. Each event, the contractor's 25 scanners receive single-use keys on their own VLAN, with expiry set to the end of the event day.

Outcome. All 25 contractor keys expire automatically after each event, with nothing to revoke by hand. Contractor devices never hold a key that reaches the till segment. Signage caps mean a content push cannot slow concession payments at half-time.

What does PPSK cost, and what do you get back?

PPSK needs no new hardware. Your cost sits in four places:

  • Design time. Building the inventory, agreeing segments and writing firewall rules.
  • Switch changes. Trunking segment VLANs to every AP, which is usually a template push.
  • Store visits for unmanaged devices. Printers and cameras without MDM need a local change.
  • A key service for MAC binding. On Meraki, that means a RADIUS service such as Purple Access. Check your Meraki and Mist licence tiers with your reseller.

The return is easiest to see in arithmetic. In the fashion chain above, rotating a shared key means touching 3,000 devices. Assume five minutes per device, and one rotation costs 250 hours of store and IT time. With PPSK, the same event costs one key change. The bigger return is containment: a lost scanner exposes one device's segment, not the payments network.

Purple runs at 80,000+ live venues and handled 440 million logins in 2024 (Purple's own data). Purple holds ISO 27001 certification. Guest marketing on the open network sits in Engage. DNS filtering for any segment is Shield, a separate add-on. For the open and secure networks, browse our Access guides.

Frequently asked questions

Do we need new access points to run PPSK in our stores?

No. PPSK runs on the access points you already own. Cisco Meraki MR access points support it as Identity PSK, and Juniper Mist access points support it as Multi PSK. Purple Access is hardware-agnostic and layers on top of Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet as a cloud overlay. You change SSID settings, VLAN trunks and policies, not hardware.

Will PPSK satisfy our PCI DSS assessor?

PPSK gives you evidence for PCI DSS, not a pass on its own. Per-device keys support requirement 2.3.2, which asks you to change wireless keys when someone who knows them leaves or a key is compromised. Moving tills onto their own VLAN supports requirement 1 and can reduce the systems in scope. Your Qualified Security Assessor decides what counts, so export your key register, policies and test results for them.

Should store devices use PPSK or 802.1X certificates?

Use certificates wherever a device can enrol and renew one, and PPSK for everything else. IEEE 802.1X with EAP-TLS stays the default for staff laptops and phones under MDM. Most tills, printers, signage players and cameras cannot enrol certificates at scale, and many support only WPA2-Personal. PPSK gives those devices per-device identity, VLAN and revocation without changing the device itself.

Can we move devices off a shared staff password without visiting every store?

Yes, for devices you manage through MDM. Push the new device SSID, its per-device key and a fixed-MAC setting as one profile. Then confirm each device lands on the right VLAN. Devices without MDM, such as many printers and cameras, need a local change or the vendor's configuration tool. Plan those into existing store visits, and keep the old SSID live until the last device moves.

What happens if a scanner randomises its MAC address?

A MAC-bound key will reject it, so disable randomisation for the device SSID. Android 10 and later use a randomised MAC per network by default, and most rugged scanners run Android. Set the WiFi profile to use the device MAC through your MDM. Randomisation protects people's privacy on public networks. It adds nothing for a managed till or scanner joining your own network.

Does Purple Access also cover shopper WiFi and content filtering?

Yes, on separate networks managed from one platform. Shoppers join the open network through a captive portal, with marketing and conscious-choice opt-ins handled in Engage. Staff join the secure network with certificates or Microsoft Entra ID, Okta or Google Workspace sign-in. DNS filtering is Shield, a separate add-on. Devices stay on xPSK, so a till never shares a network with a shopper's phone.

How much effort does a PPSK rollout across a store estate take?

Expect most of the effort before the first key exists. Building the device inventory with MAC addresses takes longer than console work. So do agreeing segments with payments and CCTV owners and trunking VLANs to every access point. Once one pilot store passes every test, later stores reuse the same policies and key template. Devices under MDM move remotely, while unmanaged printers and cameras set the pace of each wave.

Frequently asked questions

Do we need new access points to run PPSK in our stores?

No. PPSK runs on the access points you already own. Cisco Meraki MR access points support it as Identity PSK, and Juniper Mist access points support it as Multi PSK. Purple Access is hardware-agnostic and layers on top of Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet as a cloud overlay. You change SSID settings, VLAN trunks and policies, not hardware.

Will PPSK satisfy our PCI DSS assessor?

PPSK gives you evidence for PCI DSS, not a pass on its own. Per-device keys support requirement 2.3.2, which asks you to change wireless keys when someone who knows them leaves or a key is compromised. Moving tills onto their own VLAN supports requirement 1 and can reduce the systems in scope. Your Qualified Security Assessor decides what counts, so export your key register, policies and test results for them.

Should store devices use PPSK or 802.1X certificates?

Use certificates wherever a device can enrol and renew one, and PPSK for everything else. IEEE 802.1X with EAP-TLS stays the default for staff laptops and phones under MDM. Most tills, printers, signage players and cameras cannot enrol certificates at scale, and many support only WPA2-Personal. PPSK gives those devices per-device identity, VLAN and revocation without changing the device itself.

Can we move devices off a shared staff password without visiting every store?

Yes, for devices you manage through MDM. Push the new device SSID, its per-device key and a fixed-MAC setting as one profile. Then confirm each device lands on the right VLAN. Devices without MDM, such as many printers and cameras, need a local change or the vendor's configuration tool. Plan those into existing store visits, and keep the old SSID live until the last device moves.

What happens if a scanner randomises its MAC address?

A MAC-bound key will reject it, so disable randomisation for the device SSID. Android 10 and later use a randomised MAC per network by default, and most rugged scanners run Android. Set the WiFi profile to use the device MAC through your MDM. Randomisation protects people's privacy on public networks. It adds nothing for a managed till or scanner joining your own network.

Does Purple Access also cover shopper WiFi and content filtering?

Yes, on separate networks managed from one platform. Shoppers join the open network through a captive portal, with marketing and conscious-choice opt-ins handled in Engage. Staff join the secure network with certificates or Microsoft Entra ID, Okta or Google Workspace sign-in. DNS filtering is Shield, a separate add-on. Devices stay on xPSK, so a till never shares a network with a shopper's phone.

How much effort does a PPSK rollout across a store estate take?

Expect most of the effort before the first key exists. Building the device inventory with MAC addresses takes longer than console work. So do agreeing segments with payments and CCTV owners and trunking VLANs to every access point. Once one pilot store passes every test, later stores reuse the same policies and key template. Devices under MDM move remotely, while unmanaged printers and cameras set the pace of each wave.

Turn this guide into a plan for your estate

Tell us about your sites and the hardware you run. A Purple engineer maps Purple Access on top of it with you, and you keep the plan.

  1. Get your three-SSID plan in 45 minutesTell us what runs on your WiFi today, and a Purple network engineer maps it with you.
  2. Map your SSIDs onto threeOpen, secure and xPSK, on the access points you already own. You leave with the plan.
  3. Prove it on one site firstJudge the result on tickets and audit evidence, then roll out.

Your design session

45 minutes. Your estate. A plan you keep.

Led by a Purple network engineer. No slides. You keep the plan.