TLP:CLEAR

# Public WiFi Policy

## Draft for Approval by Company Directors, 22 April 2026

Latest published version:
  https://www.sr2.uk/policy/public-wifi/
Version:
  1.0

© SR2 Communications Limited. This document is licensed under CC BY 4.0.

## Abstract

A policy governing staff and contractor use of public WiFi networks when accessing company data.

## 1. Objective

The company approves remote working to work-related cloud services and work email accounts, as long as the devices used to access these have been sanctioned by the company. Using public WiFi to conduct business, without the necessary safeguards, places our data at risk of theft. The purpose of this policy is to provide the framework for those safeguards.

## 2. Scope

The scope of the policy covers all individuals either employed or contracted to work with, or for, the company, either on a company site or remotely.

## 3. Definitions

Public WiFi Network

  Any wireless network access provided by a third party, such as hotels, cafes, airports, or public hotspots, that is open to public or unvetted access. For the purpose of this policy, eduroam connections other than those on an SR2 managed site are to be considered Public WiFi Networks.

Sanctioned Device

  A device (e.g., laptop, tablet, smartphone) that has been approved and provisioned by the company for business use, with appropriate security configurations and software installed.

## 4. Policy

Devices that are not sanctioned by the company, including home PCs or public access PCs, MUST NOT be used to access company cloud services, data, or email accounts.

Though the company takes every effort to ensure that sanctioned devices are adequately protected, the individual MUST ensure that, before connecting to the Wi-Fi network, the device has:

- up-to-date antivirus and antispyware software;

- a firewall that is activated and configured to company requirements (i.e. the settings have not been changed) since the device was configured;

- all software (including the Web browser) is current with automatic updating;

- file sharing (e.g. SMB) is switched off.

For security reasons staff and contractors MUST:

- consider if mobile phone tethering is available and use this as the first choice;

- consider delaying transmission of information until at a secure location;

- not follow prompts to update software whilst connected to a public network;

- not rely on the encryption provided by the Public WiFi Network (e.g. WPA) to protect company data;

- ensure that an end-to-end encrypted connection is established and the user has been trained in setting up such a connection for each service to be used (for the avoidance of doubt, TLS is considered to be end-to-end providing that the certificate presented by the server is validated);

- ensure that URLs in Web browsers are showing the correct Web addresses in case a criminal has hijacked the Wireless Access Point and is forwarding traffic to their site;

- keep all information secure, including restricting the view of the screen from any unauthorised person(s);

## Conformance

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.

All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

Examples in this specification are introduced with the words “for example” or are set apart from the normative text with `class="example"`, like this:

This is an example of an informative example.

Informative notes begin with the word “Note” and are set apart from the normative text with `class="note"`, like this:

Note, this is an informative note.

## References

### Normative References

[RFC2119]
  S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119