Sharing workplace wireless networks

Using recommended patterns for workplace wifi networks and sharing infrastructure.

This guidance replaces CESG architectural pattern 12, which always requires the use of a VPN over a wireless network.

Read this guidance if you’re deploying new or upgrading existing government networks to understand:

  • how using common network names and authentication mechanisms provide roaming access for users across all government buildings
  • how sharing wired and wireless networks reduces cost and infrastructure duplication
  • how to set up appropriate controls to manage security risks
  • how to standardise network access for end user devices across wired and wireless networks
  • coverage, density and radio frequency management for new or upgraded wifi implementations
  • network separation, security, management, monitoring and migration
  • why you should avoid certain wifi practices and patterns for security and performance reasons

This guidance provides access patterns for:

  • automatic joining or roaming of all government owned and managed devices with a standard service set identifier (SSID)
  • controlled guest access to government workplace wifi

It describes how to retrofit these patterns to existing wifi and public key infrastructures (PKI).

Follow this wifi technical specification


Devices should access government wifi networks by either one of:

  • automatic joining of trusted networks using certificates
  • user-initiated sign in with minimal staff management overhead

Service providers must:

  • use cross-government authentication solutions to allow clients to roam
  • minimise the intervention required by users trying to gain wifi access
  • standardise the process by which access is provided to a specific set of SSIDs
  • provide an acceptable use policy (AUP) for users, where they have not already agreed to one as part of the sign in process
  • ensure that logging and auditing of wifi network use is in line with the current legal requirements and the organisation’s security policy
  • be prepared to answer official requests for information

  • limit the SSIDs broadcast, documenting exceptions

Network separation

Network separation is required to share government wifi resources. You must put mechanisms in place to isolate wireless wifi traffic by:

  • SSID
  • certificate authority (CA), identified by a device certificate

Service providers must:

  • provide a mechanism for separating wifi network traffic belonging to users of particular classes (such as guests and different organisations), using one of the following methods:

    • connecting to separate virtual local area networks (VLANs) at the wifi access point (AP) where they are standalone or cloud managed
    • separating traffic at a central point like a wireless controller — traffic should be securely tunnelled from the AP to the tunnel termination point where it can be more easily separated from different VLANs or interfaces, or tunnelled to a different controller
  • employ separate IP addressing, routing and access controls for each wifi network
  • prioritise and manage the competing bandwidth requirements of the different classes of user
  • isolate wifi clients from one another to prevent a compromised device attacking others on the network - where a wireless client provides services, you should move it to a different VLAN

Service providers should:

  • deploy guest wifi on a workplace network using the separation methods above
  • consider complementing wifi with remote access solutions, like client VPNs, to provide end security for devices connecting back to ‘home’ organisation networks or platforms
  • consider using encrypted tunnels between access points and controllers
  • consider the benefit of providing ‘home’ organisation users access to corporate resources and local breakout to cloud services
  • consider implementing location-based restrictions like geofencing tools to restrict access to back-end systems to specific locations

Bandwidth and access

Users expect wifi to be as good as they have at home. For most locations, the cost of commodity bandwidth is low enough for organisations to over provide it cost effectively. By doing this, organisations:

  • allow for a wide variety of media rich applications
  • avoid complex systems and policies to curb user requirements which push them to alternative methods, like mobile data

Service providers should:

  • provide an internet connection with a basic content filtering service to all wifi users (filtered domain name system (DNS) is an appropriate solution)
  • provide a suitable amount of bandwidth for the planned number of users using commodity internet services
  • avoid restricting sites or applications in an attempt to reduce bandwidth requirements - in most locations it’s cheaper to over provide bandwidth

Service providers should consider the most cost effective way to improve user experience at a site, which may include:

  • transparent caching technologies to minimise the impact of software updates
  • quality of service (QoS) - however, this is not a long term solution to inadequate bandwidth
  • upgrading bandwidth using commodity internet services


When deploying workplace wifi, service providers should:

  • manage channel selection (radio frequency) and reduce power if necessary, to minimise contention and overlapping — ideally use the automatic channel selection features present in enterprise wifi management systems rather than manual configuration
  • deploy centrally managed AP hardware, each with at least 5 GHz frequency band and 802.11ac support (ideally with ac wave 2 and multi-user multiple input multiple output (MIMO) support)
  • ensure there’s sufficient uplink bandwidth from APs to the building switch infrastructure
  • use 802.11at - type 2 capable switches to power the access points and allow easier upgrade to future wireless technologies
  • disable low-bandwidth wifi protocols like 802.11a and 802.11g on the 5 GHz band which should only support 802.11n, 802.11ac or faster and confine legacy clients to the 2.4 GHz band
  • configure a high minimum basic data rate and disable lower data rates — this encourages clients to roam to APs with stronger signals, and increases capacity for all clients
  • plan for 50% of the AP vendor’s recommended client device count per AP radio — stay well under the vendor’s published maximum figure (you could provide one access point per block of 20 users, located in the middle of each group)
  • if possible, not exceed 4 SSIDs per band per site — each SSID will use up some bandwidth with beaconing, probe requests and probe responses

Service providers should consider:

  • selectively disabling SSIDs at places and frequencies they are not required
  • selectively disabling 2.4 GHz radios on APs in large open plan areas with more than three APs to reduce interference between APs on the same frequency — 5 GHz has considerably more channels and is better at providing non-contending overlapped coverage
  • managing channel width — GDS recommends designing 802.11n/ac using 40 MHz width channels; wider channels (channel bonding) may be enabled on a best effort basis for 802.11ac though they should be configured to fall back to a non-overlapping channel
  • enabling dynamic frequency selection (DFS) or 802.11h for 5 GHz band, which provides for a larger number of channels to be made available (note that with DFS enabled, sudden changes may occur in response to detection of radar signals by wifi APs)
  • enabling ‘band steering’ which works by regulating probe responses to clients and making 5 GHz channels appear more attractive to clients by delaying probe responses to clients on 2.4 GHz
  • standards based (802.11r) support for smoother roaming for devices on the move
  • using Wi-Fi Voice Enterprise or equivalent if voice support is required

Administration and monitoring

Service providers must:

  • ensure all users on any network have agreed to an AUP — assume government users on government devices have already done so
  • obtain user consent to use any non-anonymised data, through an AUP or individual agreement
  • provide remote monitoring to manage usage and support — the provider should handle all alerts and detect trends in usage which might require future upgrades

Service providers should consider:

  • using tools that show both current and historical network activity — in conjunction with building floor plans and access point locations this can provide a visual insight into coverage and use
  • using location data to improve business operations, like real time people finder, crowd management and emergency response, queue length reporting, hot desk/meeting room usage and path planning

Security and availability

Service providers must:

  • ensure all wifi equipment and connected infrastructure is well maintained and patched for any security vulnerabilities
  • protect access to all network infrastructure management interfaces either directly or indirectly using two-factor authentication (2FA) to mitigate the risk of a stolen password compromising the security of the entire organisation enable radio spectrum monitoring and alerting to respond to potential attacks or electromagnetic interference

Service providers should consider:

  • keeping up to date on emerging threats to wireless networks in order to implement appropriate mitigations, by subscribing to CERT-UK or another threat warning service
  • the impact of wifi controller infrastructure choices (for example directly wired on-premises controllers, dedicated on-net or cloud-managed controllers) on network availability in the event of component failure and overall security
  • processes for responding to any events where radio quality is compromised for a significant period - note that wifi networks are vulnerable to deliberate remote denial of service (DoS) or accidental interference from other radio frequency equipment (like microwave ovens, bluetooth, wireless cameras)

Wireless network names and authentication

Two cross-government SSIDs should broadcast across all participating government buildings which, between them, meet almost all requirements. These will authenticate using a central service to allow for roaming between buildings and provide the illusion of a single wireless network across government to users.

The GovWifi service:

  • requires user sign up
  • provides access to the internet only
  • does not allow users to access any internal systems

The DeviceWifi service:

  • is wifi that automatically and securely connects government managed devices
  • gives devices access to internal local area network (LAN) resources in ‘home’ buildings or shared buildings following the shared WAN guidance
  • doesn’t require any user set up - it just works
  • gives devices access to the internet for a VPN when roaming
  • should be deployed alongside a VPN client to switch seamlessly between a trusted ‘home’ network and VPN using the same authentication infrastructure
  • authenticates devices securely using certificates

Read more about network access profiles.

Privacy and personnel security

Consider these personnel security risks when replacing wired with wireless networks:

  1. It’s possible to track users from a workplace as they use their devices in public. Each device has a unique hardware address known as a media access control (MAC) address, which is broadcast continuously via radio when connected to a wireless network but also periodically when disconnected. This could be used to track users from their workplace to a public area.
  2. Devices broadcast this information to detect whether they are in range of previously connected networks. This also allows an attacker to make assumptions about the user’s identity based on the networks they have previously used. Use visible rather than hidden SSIDs.
  3. When a user has previously connected to any open wifi network, an attacker can force their device to connect to that network and intercept traffic causing loss of privacy, theft of credentials or delivery of targeted malware.

To mitigate these risks you should:

  • never connect to an open (unencrypted) network - if this is unavoidable then delete or forget the network once you have finished using it
  • enable MAC address randomisation
  • delete or forget any sensitive networks
  • use the common cross-government common SSIDs suggested in this document as opposed to those that identify an organisation or site

You could also turn off wifi outside the workplace in high risk environments.

Use wired LAN where required

A wired LAN will still be required to connect your wireless access points.

Organisations with most users on wireless should use shared wired LANs to provide connectivity for a small number of non-wireless capable devices.

Organisations with complex or high density wired ethernet requirements, for example fixed IP telephony in a call centre environment, can continue to use their own switches.

Service providers must support client access and connectivity for the wireless access points on the same switch fabric to avoid duplication of infrastructure.

Service providers must ensure that:

  • uplinks are suitably sized for the expected level of traffic and implement QoS where appropriate
  • an uplink is at least twice the bandwidth of the fastest user connection to avoid one person impacting the network
  • shared LANs use 802.1x certificate-based authentication or restriction to an authorised MAC address on every accessible floor port
  • appropriate security measures are in place to prevent any access to other VLANs like dynamic trunking
  • the same authentication methods and servers are used for wifi and wired LAN ports to give a consistent user experience
  • guest access is not provided on wired LAN ports as it’s undesirable to encourage non-government users to plug into floor ports
  • a local RADIUS server returns vendor specific attributes (VSAs) to allow the client to access the locally allocated VLAN (in the case of a shared building with no departmental IT ownership the central RADIUS server VSAs will be directly trusted)
  • where implemented, a local RADIUS server can filter and rewrite VSAs received from the central RADIUS proxy
  • VLANs are not spanned between shared and non-shared switches unless detailed agreements are in place between the two parties to safely share a spanning tree instance and mitigate the impact of a broadcast storm

Remove requirements for per desk floor ports by:

  • using laptops rather than desktops
  • installing wireless cards in desktops
  • using wireless printers

The design should still support a small number of wired clients to allow for future requirements.

Use these network access profiles

Choose your access profile depending on who owns the device and how it’s configured.

Use GovWifi if:

  • the device is owned by the user
  • the device is owned by a third party organisation
  • the device is owned by the organisation which uses internet cloud services only and manages the device using mobile device management
  • you use a strict ‘always-on’ VPN - a specific type of VPN configuration which routes all traffic via a central point and doesn’t allow the device to communicate outside of the VPN tunnel

Use DeviceWifi if:

  • the user has a managed device without an ‘always-on’ VPN
  • the user has a managed device with a selective ‘always-on’ VPN policy which allows direct communication on trusted networks

Privileged network access

GDS recommends that privileged network access is authenticated using certificates and that the certificate is checked for validity using an up to date certificate revocation list (CRL) or using Online Certificate Status Protocol (OCSP).

PKI certificates provide strong authentication of devices and users, and can’t be stolen by rogue networks. They are also almost impossible to extract from devices when the private key is stored in a trusted platform module or smart card.

Different access levels can be granted by using VLAN assignment by the RADIUS server, or different SSID names. However, using multiple SSIDs for different accesses is not a scalable solution.

Any RADIUS server that assigns VLANs must be secured to the level of the highest security VLAN that will be honoured by the infrastructure. This may involve protecting the RADIUS traffic in an encrypted tunnel if the server is remote.

Use a system for checking guest certificates to enable cross-government roaming. The components are:

  • a central RADIUS proxy - this acts like a telephone exchange routing requests back to the ‘home’ organisation
  • a CA in each organisation - some organisations will need a new subordinate CA dedicated to network authentication; Windows environments include Microsoft Certificate Services with Windows Server, and devices can be automatically issued certificates using group policy
  • a RADIUS server - this validates certificates presented when the organisation’s own devices authenticate to the network; Windows environments include Microsoft Network Policy Server with Windows Server

The diagram below shows authentication infrastructure via a central RADIUS proxy. A central authentication proxy routes authentication requests to each organisation’s authentication server. In non-shared buildings devices authenticate to the organisation’s local server first. Requests from devices that belong to different organisations are passed to the central RADIUS proxy. The central RADIUS proxy sends the request to the device’s home server. Shared buildings send their authentication requests directly to the central RADIUS proxy.

Example authentication infrastructure via a central RADIUS proxy

To route requests correctly, certificates issued by organisations need to be easily identifiable.

You’re recommended to use the following format for certificate names:

  • devicename is the computer hostname or asset tag
  • unit is used if separate PKIs are deployed within an organisation
  • is your public registered domain name

Existing certificates that don’t conform to this standard may be supported as long as there is a unique pattern that isn’t matched by any other organisation’s certificates.

User-initiated internet access for staff and guests

This method provides an alternative where no certificate is available to grant access to the network. For example, it may be appropriate for:

  • organisations that have not deployed certificates to devices
  • visitors from outside government
  • staff with devices without suitable certificates
  • personal devices of members of staff

The Government Digital Service (GDS) provides a central authentication service which meets the requirements of this guidance and allows users to roam seamlessly between participating buildings.

Service providers must provide:

  • this access method on all wifi installations
  • adequate signage to inform users of the service
  • an SSID called GovWifi when using the GDS service of type WPA2-Enterprise Advanced Encryption Standard (AES)
  • authentication using the central authentication solution using the Microsoft Challenge Handshake Authentication Protocol (MS-CHAPv2) inside Protected Extensible Authentication Protocol (PEAPv0) EAP method
  • unique randomly generated usernames and passwords for each user with no ability for the user to set their own

Service providers must not:

  • implement unencrypted or open networks - they leak too much information
  • implement captive portals - these interfere with ‘always-on’ VPNs which are becoming increasingly common
  • allow the user to choose their password - they could reuse the passwords they use for other government services
  • allow access to internal or privileged networks - these should only be accessible using certificates or a VPN client
  • use pre-shared keys (PSKs) as they provide little privacy between users

Wifi service providers should email to request details on how to sign their installation up to the central authentication solution.

Wifi for members of the public

Consider the options below for providing public access.

Unencrypted network

In low risk environments, it may be acceptable to deploy unencrypted wifi networks, where ease of use is more important than the security of the users. Document this assessment.

Pre-shared key

In low risk environments, it may be acceptable to deploy PSK wifi networks, where ease of use is more important than the security of the users. Document this assessment.

WPA2-Personal can be used as a basic method to restrict access to those who know the code. Workplace networks protected using PSK provide no additional security over an unencrypted network as anyone who knows the passphrase can derive the individual client encryption keys.

Per user credentials

A WPA2-Enterprise network is the most secure solution with individual passwords, although it’s harder for users to configure. The sign in process must be as straightforward as possible.

Non-standard methods

Some wifi vendors provide proprietary methods like supporting a per user PSK. This can offer good security and ease of connection but is not standards based so can’t be used in multi-vendor environments.

Basic web filtering is necessary, but as Secure Sockets Layer (SSL) decryption is not possible with unmanaged devices, a proxy solution may not add much value. Filtered DNS may be a more cost effective solution.

Service providers should consider:

  • the appropriate level of content filtering
  • whether an AUP is required
  • the most effective way to deliver the AUP to the users
  • the security and traceability of the users
  • the auditability of the solution
  • the obligations imposed on you through legislation

Implement the design

For high density enterprise wifi you must carry out a site survey before final tendering or implementation. Typically this involves an ‘AP-on-a-stick’ pre-deployment map of the sites and an AP coverage and positioning plan. GDS also recommends doing a post deployment check or post deployment survey to ensure performance and coverage is as expected.

The brief for the survey team should specify that the goal is a high-capacity wifi network rather than a coverage-oriented wifi network, and that there are likely to be multiple wifi capable devices per person in the building. If location services are required as part of the solution then this should also form part of the survey brief.

Buildings where all data cable ports are below a raised floor may not have suitable cabling to support the solution. The cost of providing new or upgraded cabling can be significant. Existing wired network switches must support power over ethernet (PoE) at a sufficient level to support the required APs. Higher power levels (802.11at) should be strongly considered to support future wifi equipment. GDS recommends that two cables are installed to each AP location to allow for the higher bandwidths of 802.11ac and future technologies. When choosing cabling, consider emerging ethernet technologies like 2.5 Gb and 5 Gb ethernet which are ideal for high speed wireless access point backhaul and require Category 5e cable and Category 6 cable respectively.

The internal structure of each building plays a significant role in wifi network performance. Thick internal walls may attenuate radio — counter intuitively this can improve wifi performance by reducing channel contention.

Assess how far wifi coverage extends external to the building fabric, particularly, where the building may be high profile and/or situated within a densely populated public area.

Outside the wireless network itself, other infrastructure may need upgrading or scaling during a widespread wireless rollout, including internet bandwidth at offices, hosting centres and VPN and firewall systems.

Buy the solution

You can buy a solution following this pattern using the Network Services framework. A Crown Commercial Services buyer’s guide is being created to provide further clarity on the catalogue items required to construct this service.

Avoid multi-tenant government buildings with overlapping networks

Don’t implement the following patterns in new solutions. If you must use one of these patterns to support a legacy solution, follow advice from GDS to mitigate some of the risks. Phase these patterns out in favour of those described earlier in this guidance.

Multi-tenant government buildings with overlapping networks

Government organisations often share office buildings. In some cases multiple wifi networks have been deployed by different organisations without sharing or coordination. These networks will tend to overlap, interfere and compete with one another, which reduces the availability and speed of the networks for all users. Commission a wifi survey to discover any problems that overlapping networks are creating in an existing shared space. For shared office buildings GDS recommends a single wifi infrastructure managed by an integrated controller system. Different organisational needs can still be met with multiple VLANs and SSIDs if required. Only a single infrastructure can automatically deliver optimal spectrum efficiency in a shared space. The alternative to a single managed infrastructure in a shared space is to:

  1. Carry out pre-surveying.
  2. Plan extensively
  3. Make agreements between all parties on frequency bands and power levels
  4. Carry out further surveying
  5. Manually configure radio configuration of APs.

Government organisations must not share office spaces without coordinating their wifi network deployments.

Avoid pre-shared keys for guests

Often guest wifi is offered based on WPA2-Personal encryption using a PSK. Typically these networks are on an SSID and can also allow ‘bring your own device’ (BYOD) access to staff, or provide access to staff or visitors working on corporate devices (for example a laptop with a VPN).

Access control in these cases should:

  • use WPA2 with PSK — also called Personal WPA2 or EAP-PSK — using AES
  • have a long PSK (short PSKs are vulnerable to brute force attacks) - four randomly selected words provide an adequate balance of security and ease of use - read CESG guidance on passwords
  • advise visitors of the SSID and PSK on arrival and use building signage to advise staff — but this should not be visible in public areas
  • rotate PSKs at regular intervals
  • not provide privileged LAN network access — only provide standard internet access with malware filtering
  • force pre-acknowledgement of terms and conditions or AUP
  • not make assumptions about end user device security — devices must be isolated from one another

This approach is not recommended due to the:

  • difficulty of managing PSKs — in practice, despite the best intentions, they are seldom rotated, and when they are this is disruptive to many users
  • difficulty in enforcing agreement to AUPs
  • inability to distinguish guest traffic from corporate devices preventing traffic prioritisation
  • illusion of security it creates which is misleading to end users
  • interruptions when roaming from AP to AP in solutions based on Wireless Protected Access 2 (WPA2)-PSK, which may cause video or audio problems

Where deployed this approach should be considered as a legacy stop-gap pending implementation of a more robust solution.

Avoid PSK for legacy devices

There are some devices where signing into organisational PKI and/or VPN infrastructure is not feasible, but building LAN or organisational access is required — for example environmental monitoring, hand-held barcode scanning or digital signage devices. Access control for these devices should:

  • use WPA2-Personal with a PSK using AES
  • use a long PSK — at least 24 random characters which must be rotated at regular intervals
  • use an SSID comprising random characters
  • prevent sign in or access to any devices that might share the PSK (for example iOS with iCloud Keychain, Windows 10 with wifi sense enabled)
  • ensure minimal privileged network access is available from the SSID — restrict to the local network services that are required, and never provide open LAN/WAN/Public Services Network access
  • run at the minimum possible power level on the AP(s) to support the network and disable SSID or radio when not in use
  • restrict the SSID and PSK to a single security level
  • monitor any attempts to join the network

Never use these insecure wifi patterns

Service providers must not implement the following patterns, and where they exist should create a plan to replace them.

Never rely on hidden SSIDs for security

Devices connecting to the network will be broadcasting the SSID which can be easily picked up by an attacker. Any clients will also be continuously broadcasting the SSID even when out of range, causing privacy concerns. The salt used to hash the pre-shared key uses the SSID name. A blank SSID name is one of the most common wireless network names and is vulnerable to a rainbow table attack.

Never deploy Wired Equivalent Privacy (WEP)

This protocol is cryptographically weak and should not be considered secure.

Never deploy WPA or use Temporal Key Integrity Protocol

WPA uses Temporal Key Integrity Protocol (TKIP) which is vulnerable to:

  • Beck-Tews attack
  • Ohigashi-Morii attack

These attacks could result in a compromise of privacy.

Never use directory credentials to connect to a network

A rogue network with the same name can easily steal the username and password of a user. The attacker can then gain access to other services like email or VPN. This can only be prevented by robust certificate checking by the client policy or user.

This risk still exists even where the authentication is mediated via RADIUS and robustly protected using Transport Layer Security (TLS) encryption, for instance Protected Extensible Authentication Protocol (EAP-PEAP).

An attacker could try and connect to the network with the wrong password until the account locks, then call the helpdesk pretending to be the user to get a new password.

Never use pre-shared keys for privileged network access

Use EAP-PSK to provide any form of privileged LAN access except legacy devices if unavoidable.

Never authenticate with EAP methods: Lightweight EAP (LEAP) or Message Digest 5 (MD5)

EAP-LEAP relies on the security of Microsoft Challenge Handshake Authentication Protocol version 2 (MS-CHAPv2) which is not secure and can be cracked using an offline dictionary attack or using brute force within a day on specialised hardware. EAP-MD5 does not authenticate the wireless network so provides no protection against rogue access points. The hash is also vulnerable to dictionary and cryptographic attacks.

Never use wifi Protected Setup (WPS)

This relies on an 8-digit number which is checked separately as a group of 4 and a group of 3 digits (the last digit is a checksum). This gives 11000 different combinations which is easy for a computer to crack in a short timeframe.

Never allow any unmanaged wifi APs to connect to government networks

All APs should be centrally managed and monitored to ensure compliance with this guidance, secure configuration and timely security patching.

Never use MAC address filtering for security

This method gives an illusion of security but only makes it difficult for your users to get connected. Attackers will be able to clone a legitimate user’s MAC address very easily.

Never deploy clients that do not authenticate the wireless network

The client must check the signing certificate authority and certificate name to prevent connecting to a rogue access point. This could allow the credentials to be stolen (somewhat mitigated by only using credentials of no value) and traffic to be intercepted.

Read more about networks

Read about sharing wide area network connections in shared buildings if you provide network infrastructure to government organisations. Find out about GovWifi.

Email questions and feedback to

Published 21 July 2016