Microsoft PKI Best Practices

A Public Key Infrastructure (PKI) is an 802.1x network security solution that uses public-private key cryptography to authenticate users for online resources. PKIs can be configured to authenticate for Wi-Fi, web applications, VPN, desktop logon, and much more.

However, setting up a PKI can be a laborious task depending on the type of PKI you choose. Plus, using an on-premise legacy PKI system will leave you having to find workarounds or extensions for new releases. A managed cloud-based PKI is much more versatile, one-third the cost, and can easily fit into your infrastructure. Check out how easy it was for our customers to configure SecureW2’s PKI solution.

Here are some best practices for Microsoft environments when implementing a PKI:

Don’t Use AD CS for PKI

AD admins can use Active Directory Certificate Services (AD CS), a Microsoft server role that allows admins to build a PKI and roll out certificates. A huge benefit is AD CS can connect to AD and register users for certificates with their identifying information in AD. While this may seem like a logical choice for Microsoft admins, going with AD CS is usually not a good idea.

For starters, AD CS was built for Active Directory (AD), which requires an on-premise server to operate. That sets a bad precedent for organizations aiming to migrate their networks completely cloudward. The best implementation of AD CS in 2020 requires admins to continue using their on-prem legacy system and create a hybrid network with some cloud capabilities.

A PKI with AD CS is also one the more expensive solutions because it requires a team of trained PKI experts dedicated to PKI management and the high cost of implementation. Organizations will need to pay for hardware and software implementation, licensing fees, infrastructure, eventual replacement and much more. With an on-prem PKI, admins will end up paying more for a solution that takes months to fully implement.

Choose A Managed PKI Solution

None of this is necessary with a managed PKI service, which can be set up in a few hours, and costs a fraction of the price of on-prem PKIs. The workload involved with building PKIs are shifted away from the IT admins. Enterprises only need one part-time PKI manager, no expensive team of experts required.

SecureW2’s cloud-based Managed PKI is the best option because it’s a turn-key PKI solution that requires no forklift upgrades and can be enabled in less than an hour.

Use 802.1X EAP-TLS Authentication

802.1X is a network protocol that authenticates users and is imperative for secure network access. What makes 802.1X so unique is that it uses a RADIUS server, which checks a user’s information to determine if they’re an active member and what they are allowed to access.

However, not all 802.1X protocols were created equal. Avoid using credential-based protocols like EAP-TTLS/PAP or PEAP-MSCHAPv2, because both can be exploited by cyber attacks. Besides, credentials just aren’t a secure form of authentication because they are shared often or stolen. In fact, most cyber attacks occur with stolen credentials.

The best PKI security practice is authenticating users with certificate-based EAP-TLS authentication. Admins can leverage certificates to authenticate users instead of a password. EAP-TLS eliminates over-the-air credential theft, even if a certificate were to be lost, it’s virtually impenetrable and an admin can easily revoke it, rendering the certificate unable to access the network.



During EAP-TLS authentication, the RADIUS server checks the Certificate Revocation List (CRL), a list that contains every revoked certificate. Without the CRL, the RADIUS server won’t know what certificates have been revoked and could grant access to an unauthorized user.

A properly configured CRL can run itself with little admin interaction. However, it relies on the admins remembering to revoke certificates, which might not always happen, creating a security risk. Luckily, SecureW2 has improved upon RADIUS with features to address this oversight.

Configure a Cloud RADIUS Server

SecureW2’s CloudRADIUS is an improved RADIUS solution because it’s powered by a Dynamic Policy Engine and strengthens 802.1X EAP-TLS authentication.

Standard EAP-TLS authentication involves storing user attributes on a certificate so the RADIUS can verify the user and apply policies right then and there. But certificates are static, meaning they can’t be modified after creation. This creates an issue because, if a user’s permissions change, an admin will have to manually revoke the certificate, create a new one, sign it with the CA, and administer it to the user.

SecureW2’s CloudRADIUS uses our proprietary Dynamic Policy Engine that can directly reference any cloud identity provider, including Microsoft Azure. CloudRADIUS can directly reference a directory entry and check if the entity is authorized and any additional info attached to that entry.

With a Dynamic Policy Engine, user attributes don’t have to be stored on the certificate. Instead of going through the entire certificate lifecycle multiple times just because one user’s policies changed, admins can instead edit user attributes with our easy-to-use GUI interface. CloudRADIUS can perform runtime-level policy decisions and changes take effect instantly, rather than 24 hours.

Enable MFA

Multi-Factor Authentication (MFA) drastically improves network security because it requires more than one form of identity for authentication. The three factors of MFA are: something you know, something you have, and something you are.

But just like 802.1X, the level of security depends on how networks implement MFA. Organizations that use credentials as one of the factors will still suffer from the security gaps brought on by credential-based authentication.

Again, the key is using digital certificates as a form of identification. Certificates can be locked onto network devices, automatically connecting devices to the network for the life of the certificate.

Use Enterprise CAs Instead of Standalone CAs

A common best security practice is setting up a Standalone CA, one that doesn’t need to be on the domain. Network admins can use Standalone CAs as the root CA and issue certificates to intermediate CAs, which subsequently issue certificates to users.

Since it’s not required to be on the domain, standalone CAs can be locked in a secure room and offline for long periods of time, signing on again to issue new certificates.

The offline CA method is noted for its security, but is becoming outdated with the adoption of cloud-based services. Online Enterprise CAs can offer far more advantages and match the security of offline CAs. The key is configuring your network to implement network security policies, which Standalones are incapable of handling.

Standalone CAs are not capable of automating monotonous tasks such as enrollment. Neither do they offer certificate templates, meaning every certificate request must be made manually and approved by a CA manager, which is time consuming.

Enterprise CAs are better suited for certificate environments because they support certificate templates and can automate certain tasks like enrollment and certificate requests. Admins can configure templates and add them to the Enterprise CA for certificate issuance. Key archival and recovery is another advantage of Enterprise CAs; if you happen to lose a private key, it can be recovered and dealt with instead of risking it falling into the wrong hands.

Secure Network Authentication with SecureW2’s PKI

SecureW2’s managed PKI solution only makes it easy to distribute and manage certificates and comes with our Dynamic CloudRADIUS. By integrating our software with your current PKI infrastructure or creating a new PKI with us, deploying certificate-driven security will be safe and easy to manage. Our services are easy to use and come at an affordable price.