Políticas BYOD Seguras para Redes WiFi de Colaboradores

PODCAST SCRIPT: Secure BYOD Policies for Staff WiFi Networks Runtime target: ~10 minutes | Voice: UK English, male, senior consultant tone Purple WiFi Intelligence Platform — Staff WiFi Series --- [INTRO & CONTEXT — ~1 minute] Welcome to the Purple Staff WiFi Series. I'm your host, and today we're getting into one of the most consistently mishandled areas in enterprise network management: BYOD — Bring Your Own Device — specifically for staff WiFi. If you're an IT director, a network architect, or a CTO at a hotel group, a retail chain, a stadium, or a public-sector organisation, this episode is built for you. We're not going to cover the basics of what WiFi is. We're going to talk about the architecture decisions, the standards you need to reference, and the deployment mistakes that cost organisations real money and real compliance exposure. The core problem is straightforward: your staff want to use their personal phones and tablets for work. That's reasonable. But plugging unmanaged personal devices into the same network segment as your POS systems, your HR databases, or your payment infrastructure is an unacceptable risk. The question isn't whether to allow BYOD — it's how to allow it without compromising your core network. Let's get into it. --- [TECHNICAL DEEP-DIVE — ~5 minutes] Let's start with the foundational principle: network segmentation. Every secure BYOD deployment begins with the same architectural decision — you do not put personal devices on the same VLAN as your corporate infrastructure. Full stop. The standard approach is a dedicated BYOD VLAN, sitting between your corporate core and your guest WiFi network. Think of it as a middle tier. Staff devices get internet access and access to a defined set of approved internal resources — perhaps your intranet, your cloud productivity suite, your internal comms platform — but they are firewalled away from your payment systems, your back-office servers, and your core switching infrastructure. Now, how do you authenticate devices onto that BYOD VLAN? The answer is IEEE 802.1X. This is the port-based network access control standard, and it's been the backbone of enterprise wireless authentication for over two decades. When a device attempts to connect, 802.1X triggers an EAP exchange — Extensible Authentication Protocol — between the device, the wireless access point acting as an authenticator, and your RADIUS server as the authentication backend. For BYOD specifically, EAP-TLS is the gold standard. That's certificate-based mutual authentication. The device presents a certificate, the RADIUS server validates it, and only then is network access granted. The certificate is provisioned to the device via your MDM platform — Microsoft Intune, Jamf, VMware Workspace ONE, whatever you're running — using SCEP, the Simple Certificate Enrollment Protocol. Why certificates over passwords? Because passwords get shared, phished, and forgotten. A certificate tied to a specific device and a specific user identity is significantly harder to compromise. And critically, when an employee leaves, you revoke the certificate in your PKI, and that device loses access immediately — no password reset required, no lingering credentials. Now, on the encryption side: if you're deploying new infrastructure in 2024 and beyond, WPA3-Enterprise is your target. WPA3 eliminates the KRACK vulnerability that plagued WPA2, mandates 192-bit security mode for enterprise deployments, and provides forward secrecy via SAE — Simultaneous Authentication of Equals. That means even if a session key is compromised, historical traffic cannot be decrypted. For environments handling payment card data or patient records, this isn't optional — it's a compliance requirement under PCI DSS 4.0 and increasingly referenced in NHS Digital security frameworks. Let's talk about MDM integration, because this is where a lot of deployments fall short. Your MDM is not just a certificate delivery mechanism — it's your compliance enforcement engine. Before a device is granted access to the BYOD VLAN, your NAC solution should be querying the MDM for device posture: Is the OS patched to a minimum version? Is device encryption enabled? Is the device jailbroken or rooted? Is a compliant screen lock configured? This is called posture assessment, and it's the difference between a BYOD policy and a BYOD security programme. A device that fails posture assessment should be quarantined — placed on a remediation VLAN with access only to the resources needed to bring it into compliance, and nothing else. On the logging and audit side: every device connecting to your BYOD VLAN should generate a session record — device identity, user identity, timestamp, duration, bytes transferred, and the VLAN assigned. This isn't just good practice; under GDPR Article 32, you have an obligation to implement appropriate technical measures to ensure network security. An audit trail of staff device connections is a core component of demonstrating that obligation. If you want to go deeper on audit trail requirements, Purple has a dedicated guide on what an audit trail means for IT security in 2026 — I'll link that in the show notes. One more architectural point worth flagging: MAC address randomisation. Modern iOS and Android devices randomise their MAC addresses by default when probing for networks. This breaks MAC-based authentication and can cause issues with your RADIUS accounting. The solution is to move away from MAC-based auth entirely — which you should be doing anyway — and rely on certificate or credential-based identity. Your RADIUS server should be keying session records to user identity, not device hardware address. --- [IMPLEMENTATION RECOMMENDATIONS & PITFALLS — ~2 minutes] Right, let's talk deployment. Here's the sequence I recommend for any organisation rolling out a BYOD programme from scratch. Step one: define your policy before you touch the infrastructure. Who is allowed to register a personal device? What device types are supported? What data can be accessed from a personal device? Get this signed off by HR, legal, and the CISO before you configure a single VLAN. Step two: deploy your MDM if you haven't already, and configure SCEP certificate templates for BYOD devices. Test certificate enrollment on iOS, Android, and Windows — they all behave slightly differently. Step three: configure your RADIUS server with separate policies for BYOD versus corporate-managed devices. BYOD devices should receive a VLAN assignment attribute — Tunnel-Private-Group-ID in RADIUS terms — that places them on the BYOD VLAN. Step four: configure your wireless infrastructure. Create a dedicated SSID for BYOD, or use dynamic VLAN assignment on your existing corporate SSID — the latter is cleaner from a user experience perspective. Staff see one SSID, but the RADIUS server determines which VLAN they land on based on their certificate. Step five: implement firewall ACLs between the BYOD VLAN and your corporate core. Default deny, with explicit permits only for approved services. Document every permit rule and review it quarterly. Step six: enable session logging and integrate with your SIEM. Every BYOD connection event should be an alert-eligible record. Now, the pitfalls. The most common failure I see is scope creep on the BYOD VLAN firewall rules. Someone needs temporary access to a resource, a rule gets added, and six months later the BYOD VLAN has effectively the same access as the corporate network. Implement a change management process for BYOD firewall rules and treat them with the same rigour as production infrastructure changes. The second pitfall is certificate lifecycle management. Certificates expire. If you don't have automated renewal configured in your MDM, you will get a wave of staff unable to connect on the day their certificates expire. Set renewal to trigger at 30 days before expiry, minimum. The third pitfall is forgetting about the guest network. Your BYOD VLAN and your guest WiFi network should be completely isolated from each other. A visitor on your guest network should have no path to your BYOD segment. If you're running Purple's guest WiFi platform, that isolation is handled at the infrastructure level — but verify it in your firewall policy regardless. --- [RAPID-FIRE Q&A — ~1 minute] Let me run through a few questions I hear regularly. "Can we use WPA2-Personal with a shared passphrase for BYOD?" No. A shared passphrase provides zero per-device accountability, cannot be revoked per user, and is trivially compromised. Use 802.1X. "Do we need a separate SSID for BYOD?" Not necessarily. Dynamic VLAN assignment via RADIUS is cleaner. One SSID, policy-driven VLAN placement based on certificate identity. "What about contractors and temporary staff?" Treat them as a separate identity class in your RADIUS policy. Issue short-lived certificates — 30 or 90 days — tied to their contract duration. When the contract ends, the certificate expires. "Is WPA3 backwards compatible?" Yes, in transition mode. Your access points can support both WPA2 and WPA3 clients simultaneously. Mandate WPA3-only for new device enrolments and phase out WPA2 over a defined timeline. --- [SUMMARY & NEXT STEPS — ~1 minute] To wrap up: a secure BYOD programme for staff WiFi is not a single configuration task — it's an architecture decision, a policy framework, and an ongoing operational discipline. The non-negotiables are: dedicated BYOD VLAN, IEEE 802.1X with EAP-TLS certificate authentication, MDM-enforced device posture, WPA3-Enterprise encryption, and comprehensive audit logging. The operational disciplines are: certificate lifecycle management, quarterly firewall rule reviews, and a defined offboarding process that revokes device certificates on the day an employee leaves. If you're starting from scratch, the Purple platform gives you the analytics and access management layer on top of your existing wireless infrastructure — whether you're running a single hotel property or a 200-site retail estate. Links to the architecture guide, the audit trail reference, and the BYOD onboarding checklist are all in the show notes. Thanks for listening — we'll see you in the next episode. --- END OF SCRIPT