সুরক্ষিত BYOD এবং 802.1X নেটওয়ার্ক অথেন্টিকেশনের জন্য কীভাবে SCEP কনফিগার করবেন

Hello, and welcome to this technical briefing from Purple. I'm your host, and today we're getting into the detail on SCEP - the Simple Certificate Enrollment Protocol - and how to configure it correctly for secure BYOD and 802.1X network authentication. If you're an IT manager, a network architect, or a CTO responsible for WiFi infrastructure across a hotel group, a retail estate, a stadium, or a public-sector organisation, this is directly relevant to you. We're not doing theory today. We're doing architecture and decisions. Let's get into it. [SECTION: Introduction and Context - approximately 1 minute] Here's the problem you're likely facing. You have staff devices, contractor laptops, and personal phones all needing network access. You've probably got a mix of managed and unmanaged devices. And somewhere in your infrastructure, there's still a shared WPA2 pre-shared key that twelve people know, three of whom left the company last year. That's not a security posture. That's a liability. The answer is 802.1X - the IEEE standard for port-based network access control. It ensures no device passes traffic until it's been explicitly authenticated. But 802.1X is just the framework. The real question is what authentication method sits inside it. And for BYOD at scale, the answer is EAP-TLS with certificates provisioned via SCEP. That's what we're unpacking today. [SECTION: Technical Deep-Dive - approximately 5 minutes] Let's start with what SCEP actually does. SCEP - Simple Certificate Enrollment Protocol - was originally published as an Internet Draft by the IETF in 1999, created by VeriSign. It was formalised as RFC 8894. Its job is straightforward: automate the process of issuing X.509 digital certificates to devices at scale, without requiring a human to manually generate and install each one. Here's the four-step flow. Step one: the device connects to a SCEP endpoint - a URL hosted either on-premises via a Windows Server role called NDES, the Network Device Enrollment Service, or via a cloud PKI provider. This URL is the gateway to your Certificate Authority. Step two: the device presents a SCEP challenge - a shared secret that proves it's authorised to request a certificate. In an MDM-managed environment like Microsoft Intune, this challenge is delivered dynamically and uniquely per device, which is far more secure than a static password shared across all devices. Step three: the device generates its own private and public key pair locally. It creates a Certificate Signing Request - a CSR - using the public key and sends that to the SCEP server. Here's the critical security point: the private key never leaves the device. It's generated locally, stored in the device's secure enclave - that's the TPM on Windows or the Secure Enclave on iOS - and is never transmitted. This is why SCEP is the right choice for network authentication, not PKCS, where the CA generates the key centrally and has to push it to the device. Step four: the Certificate Authority validates the CSR, signs it with the CA's private key, and returns the signed X.509 certificate to the device. The device now has a unique cryptographic identity. Now, how does that certificate get used for 802.1X authentication? When the device connects to your WiFi SSID, the access point - whether that's Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, or Ubiquiti UniFi - acts as the authenticator. It doesn't make the authentication decision itself. It forwards the EAP exchange to your RADIUS server. That could be Microsoft NPS, Cisco ISE, or Aruba ClearPass. The RADIUS server initiates an EAP-TLS handshake. The device presents its SCEP-provisioned client certificate. The RADIUS server validates three things: the certificate chain back to the trusted root CA, the certificate expiry date, and whether the certificate has been revoked - checked against a Certificate Revocation List, or CRL, or via OCSP, the Online Certificate Status Protocol. If all three checks pass, the RADIUS server sends an EAP-Success message, and the access point opens the port. The device is on the network. This is mutual authentication. The device also validates the RADIUS server's certificate. If someone sets up a rogue access point, the device will reject it because the server certificate won't validate against the trusted CA. That's your protection against evil twin attacks. Now let's talk about the deployment sequence in Microsoft Intune, because that's the most common MDM platform we see in enterprise environments. You deploy three Intune configuration profiles, in strict order. First, the Trusted Root Certificate profile - this pushes your root CA certificate to every device so they trust your PKI. Second, the SCEP Certificate profile - this tells devices the SCEP URL, the subject name format, the key usage, and the extended key usage for client authentication. The OID for client authentication is 1.3.6.1.5.5.7.3.2. Third, the WiFi profile - this specifies the SSID, sets the security type to WPA2-Enterprise or WPA3-Enterprise, sets the EAP type to EAP-TLS, and links to the SCEP certificate profile. The order matters. The WiFi profile has a dependency on the SCEP profile, which has a dependency on the Trusted Root profile. Deploy them out of sequence and you'll get errors. One architectural decision you need to make is where to host the NDES server. It needs to be reachable from the internet so devices can enrol before they arrive on-site. The secure way to do this is to publish the NDES URL via Microsoft Entra ID Application Proxy. This avoids opening inbound firewall ports and lets you apply Conditional Access policies to the enrolment flow. For organisations that want to eliminate on-premises infrastructure entirely, cloud PKI providers - Microsoft's own Cloud PKI in Intune, or third-party options - remove the NDES dependency completely. [SECTION: Implementation Recommendations and Pitfalls - approximately 2 minutes] Let me give you the three most common failure modes we see. Failure mode one: group targeting mismatch. This is the most frequent cause of WiFi profile deployment failures in Intune. If your Trusted Root profile is assigned to a User group, your SCEP profile to a Device group, and your WiFi profile to a different User group, Intune cannot resolve the dependency chain. All three profiles must target the exact same Azure AD group - either all Users or all Devices. Pick one and be consistent. Failure mode two: CRL availability. Your RADIUS server checks the CRL to verify certificates haven't been revoked. If the CRL Distribution Point - the CDP URL embedded in the certificate - is unreachable, authentication fails for every device. This is a common cause of mass outages after network changes. Ensure your CDPs are highly available, ideally published to both an internal URL and an external URL for remote devices. Consider OCSP as a more resilient alternative to CRL checking. Failure mode three: not enforcing server certificate validation on clients. This is the single most impactful misconfiguration in 802.1X deployments. If your MDM-deployed WiFi profile doesn't specify the trusted CA and the expected RADIUS server name, devices will connect to any server presenting any certificate. That defeats the entire purpose of EAP-TLS. Always configure server validation in your WiFi profile. [SECTION: Rapid-Fire Q and A - approximately 1 minute] Let's do a few quick questions. Question: Do we need WPA3? Yes. Migrate to WPA3-Enterprise. It mandates Protected Management Frames, which blocks deauthentication attacks. All hardware from Cisco Meraki, HPE Aruba, Ruckus, and Juniper Mist supports it. Question: What about devices that can't support 802.1X - like IoT sensors or legacy printers? Use MAC Authentication Bypass as a fallback, but place those devices on a heavily restricted VLAN with no access to corporate resources. Question: How does Purple fit into this? Purple's Guest WiFi platform handles the visitor and guest access layer - the captive portal, the data capture, the analytics. Your 802.1X and SCEP infrastructure handles staff and managed device access. They run on separate SSIDs and separate VLANs. Purple integrates with Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, and Fortinet - so your hardware investment is protected. [SECTION: Summary and Next Steps - approximately 1 minute] To wrap up. SCEP automates certificate issuance at scale. The private key stays on the device - that's the security advantage over PKCS. Deploy via MDM in strict sequence: Trusted Root, then SCEP profile, then WiFi profile, all targeting the same group. Publish NDES via Application Proxy or move to cloud PKI. Enforce CRL or OCSP checking on your RADIUS server. And always configure server certificate validation on client supplicants. If you're still running a shared pre-shared key for staff WiFi, that's the change to make this quarter. The certificate infrastructure is more work upfront, but it eliminates an entire class of credential-based attacks and typically reduces WiFi-related helpdesk tickets by 70 to 80 percent once deployed. For the full technical guide, architecture diagrams, and worked examples, visit purple dot ai. Thanks for listening.