KCSIE and school WiFi: combining secure access with content filtering

Keeping Children Safe in Education (KCSIE) requires schools and colleges in England to run appropriate filtering and monitoring. The DfE's standards expect filtering on every person, guest account and device using your connection. Logs should identify the individual where possible. Pairing per-person network authentication with DNS filtering meets both demands across staff, student and guest networks.

What does KCSIE ask of school WiFi filtering and monitoring?

Keeping Children Safe in Education is statutory guidance from the Department for Education (DfE). Schools and colleges in England must have regard to it when they carry out their safeguarding duties. It makes governing bodies and proprietors responsible for appropriate filtering and monitoring systems, and for reviewing how well those systems work.

KCSIE gives the designated safeguarding lead (DSL) lead responsibility for online safety. That includes understanding the filtering and monitoring systems in place. Your network is now a safeguarding control, and the DSL needs to know how it behaves.

KCSIE groups online risk into four areas: content, contact, conduct and commerce. Filtering mainly addresses content. Monitoring is how you spot contact and conduct risks early.

The four DfE filtering and monitoring standards

KCSIE points schools to the DfE's filtering and monitoring standards for schools and colleges, first published in March 2023. They set four expectations:

1. Identify and assign roles and responsibilities to manage your filtering and monitoring systems.
2. Review your filtering and monitoring provision at least annually.
3. Block harmful and inappropriate content without unreasonably impacting teaching and learning.
4. Have effective monitoring strategies that meet the safeguarding needs of your school or college.

What the third standard means for your WiFi

The third standard is where wireless design gets specific. Filtering should apply to everyone, including guest accounts, school-owned devices and any device using your broadband connection. An unfiltered staff network or a visitor network on a separate line is a gap.

The same standard expects your system to identify the device name or ID, the IP address and, where possible, the individual. It also expects the time and date of attempted access and the search term or content blocked.

Your filtering provider should be a member of the Internet Watch Foundation (IWF). It should also block content on the Counter-Terrorism Internet Referral Unit (CTIRU) list. The UK Safer Internet Centre publishes definitions of appropriate filtering and appropriate monitoring, and providers self-certify against them. Ask any provider you shortlist for that response document, including us.

Why does KCSIE WiFi filtering depend on knowing who is connected?

Most school filters already block the obvious categories. The weak point is attribution. If your staff and student networks run on shared passwords, the filter sees an IP address and nothing else.

That IP address passes to another device each time its address lease expires. Behind address translation, a whole building can look like one address to an upstream filter. When the Designated Safeguarding Lead asks who searched for a self-harm term at 1:42 PM, the honest answer is often "a device on the high school network".

Shared passwords also leak. A staff WiFi key shared in a group chat puts students' cell phones on the staff network and its looser policy. A teacher who left last term still has the key saved. Neither event appears in any log, because the network cannot tell one keyholder from another.

Per-person authentication fixes attribution at the point of connection. Every device joins with credentials tied to a named person, so every log line maps back to that person.

How do network authentication and DNS filtering work together?

Think of it as three layers. Authentication decides who is on the network and which segment they land in. DNS filtering decides what they can reach. Logs from both, joined on IP address and time, give the administrator a named record.

Layer 1: identity when the device connects

For staff, the standard is IEEE 802.1X, the port-based access control framework behind WPA2-Enterprise and WPA3-Enterprise. The device presents credentials to a RADIUS (Remote Authentication Dial-In User Service) server, which checks them against your directory. Purple's cloud RADIUS checks staff against Microsoft Entra ID, Google Workspace or Okta. You manage one account per person, not one WiFi password per building.

Students' own cell phones, dorm consoles and classroom kit that cannot handle 802.1X need another route. Identity pre-shared keys (iPSK) give each person or device its own WiFi key on a single SSID (network name). Purple's SecurePass issues those per-person keys, so a high schooler's cell phone joins with a key that is theirs alone.

Visitors, contractors and facility rental groups join through a captive portal. This is the web page a device sees before it reaches the internet, where the visitor registers or a member of staff sponsors them. Guest WiFi handles that registration and sets a time limit on each session.

The RADIUS response can also place each device on a VLAN (virtual LAN), a logically separate network segment. Staff, students and guests then sit on separate segments with separate filtering policies, even on the same access points.

Layer 2: DNS filtering on each segment

Before a browser or app connects to a site, it asks a DNS resolver for that domain's address. A filtering resolver checks the domain against category lists. It returns a block page if the category is prohibited on that segment.

Because it acts on the lookup, DNS filtering covers every device on the segment, managed or not. It needs no agent on the device and no inspection certificate. That suits guest and BYOD networks, which the DfE standards bring into scope but which you cannot manage. Purple's Shield add-on applies content filtering at this layer.

You can enforce safe search here too. Google documents a DNS mapping to forcesafesearch.google.com that forces SafeSearch on any device using your resolver. YouTube supports a similar mapping to restrict.youtube.com for Restricted Mode.

Layer 3: joining the logs

RADIUS accounting records which identity held which IP address, and when. The DNS filter records which IP address requested which domain, and when. Join the two on IP and timestamp, and a blocked lookup becomes a named student, device and search term.

That join is what the third standard means by identifying the individual where possible. It also supplies evidence for the annual review the second standard requires: which categories were hit, how often and on which network.

Staff, student and guest networks compared

Network	Who connects	How they authenticate	Identity source	Filtering policy	What the log names	How access ends
Staff	Teaching and support staff, board members	802.1X (WPA2- or WPA3-Enterprise)	Microsoft Entra ID, Google Workspace or Okta	Illegal and harmful content blocked, wider access for teaching resources	Named staff account and device	Account disabled in the directory
Student, school-owned devices	Students on school laptops and tablets	802.1X with student accounts, or a per-device key	School directory	Age-appropriate policy by grade level, safe search enforced	Named student or asset-tagged device	Student removed from the directory
Student BYOD	High school students' own cell phones and laptops, where policy allows	Per-person iPSK through SecurePass	School directory	Student policy plus VPN, proxy and encrypted DNS categories blocked	Named student and device	Personal key revoked
Guest and rentals	Visitors, contractors, parents, community rental groups	Captive portal with registration or staff sponsorship	Visitor registration record	At least the student baseline wherever children may connect	Registered visitor and device	Session expires at the time limit

Where does this sit alongside the filtering you already run?

Most schools already run some filtering. Broadband providers and regional consortia often supply it, and many firewalls include web filtering. School-owned devices may carry a filter agent delivered through mobile device management (MDM). Network authentication and DNS filtering add to these controls rather than replacing them outright.

Approach	What it sees	Covers BYOD and guest devices	Covers devices off site	Main gap
DNS filtering	Domain names looked up	Yes, any device using your resolver	No	Cannot block single pages, and encrypted DNS or VPNs bypass it unless blocked
Firewall filtering with HTTPS inspection	Full URLs and content after decryption	Domain level only, as unmanaged devices lack your certificate	No	Certificate deployment, privacy concerns and apps that break under inspection
Device agent through MDM	Activity on the device itself	No, school-owned devices only	Yes	Nothing on visitor, BYOD or unenrolled devices

The practical pattern is layering. Keep device agents on school laptops so filtering follows them home. Use DNS filtering on BYOD and guest devices that no agent reaches. Use per-person authentication so both sets of logs name an individual.

Purple runs as a cloud overlay on the access points you already own: Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet. We explain why that avoids a rip and replace in Why your next WiFi upgrade doesn't need new hardware. For SSID and segmentation design, see Network Best Practices for Venues and Enterprises in 2026.

If you move staff to WPA3-Enterprise, protected management frames (IEEE 802.11w) become mandatory. They stop forged disconnect frames, a cheap way to push a device toward a rogue network. Protected Management Frames: A Practical Guide for 2026 covers the detail.

Purple runs across 80,000+ live venues and handled 440 million logins in 2024 (Purple data), with 99.999% uptime. In education, our customers include University of Sheffield, University of Leeds and University of the Arts London. Universities sit outside KCSIE, but the identity model is the same.

What does this look like on a real school estate?

Both scenarios below are illustrative. The outcomes follow directly from the configuration described.

A high school removes three shared passwords

Situation. A high school with 1,100 students and a high school senior program runs three SSIDs. Staff share one key, high school seniors share a key changed each semester, and visitors read theirs from the front desk. Filtering sits on the broadband line. The DSL cannot attribute any blocked search to a person, and the staff key has turned up on students' phones.

What was done. Staff move to 802.1X against Microsoft Entra ID. Each high school senior receives a personal SecurePass key on a student VLAN. Visitors register through a captive portal with eight-hour sessions. DNS filtering runs per VLAN, with safe search enforced and encrypted DNS and VPN categories blocked on student and guest segments.

Outcome. Shared WiFi passwords fall from three to zero. Every filtering log line on the staff and high school networks maps to a named account. Staff access ends when IT disables the account in Entra ID, not at the next quarterly key change.

A school district opens its auditoriums for community rentals

Situation. A district of eight elementary schools rents out its auditoriums for evening clubs, weekend fairs and a Saturday soccer program. Rental groups receive each school's guest key. After several district expansions, sites run a mix of Cisco Meraki and Ubiquiti UniFi with different local settings.

What was done. The district deploys one captive portal across all eight sites as an overlay on both vendors. Site managers sponsor rental sessions timed to each booking. The rental network carries the student filtering baseline, because under-18s attend most bookings.

Outcome. Eight local guest configurations become one central policy. Every rental device links to a registered contact and booking. The district produces annual review evidence for all eight schools from one place, which answers the second standard. WiFi Analytics shows connection numbers by site, which helps the facilities team plan staffing for rentals.

What are the limits you should know about?

DNS filtering sees domains, not pages

DNS filtering decides on the domain name. It cannot block one harmful video on a domain you allow. For that, use HTTPS inspection on managed devices or controls inside the platform, such as YouTube Restricted Mode.

Encrypted DNS and VPNs can route around it

Browsers can send DNS over HTTPS (DoH), which hides lookups inside encrypted web traffic and skips your resolver. Block known public DoH resolvers and VPN and proxy categories. Then block outbound DNS to any resolver but yours at the firewall. Firefox disables default DoH when your resolver blocks its canary domain, use-application-dns.net. The FTC and state attorneys general compliance baseline expects providers to manage this kind of circumvention.

Mobile data sits outside your network

A student on 4G or 5G never touches your WiFi. Federal guidelines note that many children have unrestricted internet access through mobile networks. They expect your online safety approach to reflect that. Department of Education guidance on cell phones in schools supports prohibiting phone use during the school day.

Logs are evidence, not monitoring

The fourth standard asks for monitoring strategies, and a log nobody reads meets nothing. Agree who reviews alerts, how quickly, and how concerns reach the designated safety officer. Supervision in the classroom is part of the strategy, not a fallback.

Over-blocking carries its own risk

Federal guidance warns school boards against over-blocking that leads to unreasonable restrictions on teaching. Separate staff and student policies, graded by grade level, let a high school politics class reach news sites while 6th grade stays tightly filtered.

KCSIE applies in England only

Wales, Scotland and Northern Ireland publish their own safeguarding guidance for schools. The architecture here works in all four nations, but check local expectations.

What should you do next?

1. Map every network. List each SSID on every site with its authentication method and filter policy. Flag any network with a shared key or no policy.
2. Name the roles. The first standard expects a senior leader accountable for filtering and monitoring, the DSL leading, and a named IT provider. Write it down.
3. Test from every SSID. SWGfL's test filtering tool checks whether a connection blocks core categories, including IWF and CTIRU content. Run it from guest and BYOD networks, not just the staff network.
4. Sequence the move. Start with staff on 802.1X, because a leaked staff key exposes pupils to the loosest policy. Then add per-pupil keys, then the guest captive portal.
5. Filter per segment. Apply DNS filtering by VLAN, enforce safe search and block encrypted DNS and VPN categories.
6. Rehearse the question. Ask "who searched for this, and when?" with the DSL before an incident forces it. Record the result in your annual review.

If you also run WiFi in commercial venues, our Hotel WiFi RFP checklist: authentication, content filtering and guest marketing applies the same questions to a public estate.

Frequently asked questions

Does KCSIE require filtering on a school's guest WiFi?

Yes. The DfE filtering and monitoring standards say filtering should apply to everyone, including guest accounts, and to any device using your broadband connection. A visitor or leases network that bypasses your filter is a gap your annual review should catch. Block illegal and harmful content as a minimum, and match the pupil policy wherever children may connect, such as evening clubs, open days and holiday schemes.

Can Purple run on the access points we already have?

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. Trusts that inherit mixed hardware through academy conversions can run one authentication and filtering policy across every site. You point your controllers at Purple's cloud RADIUS and captive portal, following Purple's support documentation for your vendor.

Do we have to replace our broadband provider's filter?

No. Many schools keep their provider or consortium filter and add per-person authentication, so its logs name an individual rather than an IP address. Others add DNS filtering on BYOD and guest segments the existing filter does not reach. Whatever you run, check it meets the UK Safer Internet Centre's appropriate filtering definition. Also confirm your provider is an IWF member blocking the CTIRU list.

Is DNS filtering enough on its own to meet the DfE standards?

No. DNS filtering covers every device on your network for the filtering standard, but it sees domains rather than full pages. On its own it does nothing for monitoring. The standards also expect named roles, an annual review and a monitoring strategy run by people and led by your DSL. Combine DNS filtering with per-person authentication, device agents on school-owned equipment and supervision in the classroom.

What happens to WiFi access when a member of staff leaves?

With Identity-Based Networks, access ends when you disable the account in Microsoft Entra ID, Google Workspace or Okta. Staff authenticate through 802.1X against your directory, so no shared key stays on a former employee's cell phone. Joiners, movers and leavers follow the HR process you already run. You no longer change a shared password and re-key every device after each departure.

How should we handle students' own cell phones?

Set the policy first, then enforce it on the network. If students may not use cell phones during the day, keep them off school WiFi entirely. If high school seniors may connect, give each one a personal SecurePass key on a filtered student segment. Cell phones on 4G or 5G bypass your network, so behavior policy and supervision still matter.

How is authentication and filtering data handled under CCPA/CPRA?

Purple is CCPA/CPRA compliant and certified to ISO 27001 and Cyber Essentials. Logs that link a named student to search terms are personal data about children. Complete a data protection impact assessment before you switch them on. Set a retention period that matches your safeguarding policy, and restrict access to the DSL and named deputies. Record the lawful basis in your privacy notice.