Phishing-Resistant Authentication for Business Apps

The ultimate benefit of a private PKI is passwordless, certificate-based authentication based on asymmetric cryptography using a public key and a private key for each certificate. It’s no secret that passwords are a vulnerability, with organizations like Microsoft recommending that you move away from password-based PEAP-MSCHAPv2 to passwordless protocols like EAP-TLS. Digital certificates can be used to secure a range of resources, including your wired & wireless network, VPN, applications, desktop logins, and much more.

Additionally, there are benefits for your end-users. With digital certificates, employees no longer have to deal with frustrating password reset policies and disconnects due to password changes. Successful authentication - and access to the applications they need - is as simple as choosing the correct certificate when they log in.

There are multiple benefits to using certificates for single-sign-on (SSO). Most importantly, the security of your login is enhanced because certificates are significantly more secure than passwords. Passwords are easily stolen through a variety of attacks if they’re transmitted over-the-air, such as Man-in-the-Middle attacks. Certificates also provide device trust, as they can be tied to a device’s compliance status in an MDM such as Intune or Jamf. Because a certificate can be issued through your MDM, you have certainty about the devices accessing your platform.

Certificates grant your administrators greatly enhanced visibility over who’s accessing your business applications. A set of credentials doesn’t tell you anything because anyone can use them. A certificate, on the other hand, can be encoded with numerous attributes from your Identity Provider or MDM, such as username, MAC address, device serial number, user group, and more.

The end-user experience is also improved when you use certificates. Also SSO is already an improvement over having to log into multiple platforms with different passwords, it can be even easier when you don’t need to use passwords at all. Logging in is reduced to a couple of clicks without any need to remember a complex password.

PKI certificates can replace passwords or be used alongside them in MFA in the single-sign on process. This can look a little different depending on what your users are logging into, but with Azure CBA, for example, it means they choose to log into applications with a certificate instead.

The end-user experience is much simpler. When they log into your cloud applications through a browser, they can simply click on the certificate.

We wouldn’t be able to call it PKI as a Service if we didn’t provide you everything you needed to deploy certificates. For endpoint distribution, we have our automatic gateway APIs for managed devices and our self-service onboarding technology for unmanaged devices/BYODs.

When it comes to revocation, our cloud-based PKI can revoke certificates in a few different ways, including manually and through automatic revocation with some MDMs such as Intune. With automatic revocation, our gateway APIs can check within Intune or Jamf to see if a device has been stolen, retired, or rendered non-compliant in any other way. The certificates for these devices are automatically revoked.

You can also set the validity period for a certificate. This gives certificates an expiration date; an expiring certificate can no longer be used to authenticate once it passes that date. Access is declined automatically by Cloud RADIUS.

Our PKI makes renewal simple, too. For managed devices, certificate renewal typically happens on an automatic basis a month or two before the certificate’s expiration. For BYODs, administrators can set a customizable notification email to go out to end-users, encouraging them to re-enroll for a certificate before it expires.

Yes. Our platform can issue a client certificate to smart cards such as Yubikeys to allow for smart card-based single sign-on.

If you’re already using SecureW2’s PKI, setting up Azure AD Certificate-Based Authentication (CBA) can be done in just a few steps. In a nutshell, you’ll begin by exporting your SecureW2 Certificate Authority (CA) to Azure AD/Entra ID, then you’ll create a CBA policy in Azure and issue certificates to the users and devices you want to use the policy.

We have more detailed configurations steps in this Azure AD CBA guide for more information.

Active Directory Certificate Services is Microsoft’s legacy PKI solution that gives organizations the ability to build their own on-premise Public Key Infrastructure. Unfortunately, this often ends up being a costlier venture in terms of finances and time spent. Building a private PKI requires expertise, space for the servers, and regular maintenance. Certificate lifecycle management with Active Directory Certificate Services - from issuance to renewal to building a certificate revocation list - is time-consuming.

It’s important to understand the costs of building a PKI with Active Directory Certificate Services. Aside from taking potentially hundreds of hours to set up initially, there’s a high upfront infrastructure and software cost that can easily exceed $200,000 USD. On top of up-front software and infrastructure costs, Active Directory Certificate Services will have recurring costs in the form of high maintenance.

These costs, unfortunately, are unavoidable. A PKI is a foundational part of security systems. Rushing a configuration, or setting it up with inexperienced professionals is a huge liability. In this writeup by Specter Ops, they identify countless security vulnerabilities organizations will run into if they leave default settings enabled in AD CS. This reason alone is why many organizations choose a managed PKI.

Finally, a PKI service like ours makes it easier to manage on a day-to-day basis. You can generate whatever type of certificate you need, whether it’s a root certificate, a CA certificate, or certificates for user authentication. All of this can be achieved through a single pane of glass, saving you both time and money.

No, CBA isn’t limited to just Azure AD/Entra ID and Okta. It works with both Google and OneLogin, as well. Certificates are pretty broadly supported across different applications.

However, at the time of writing this (September 2024), most of our testing has been with Okta and Azure AD/Entra ID. The passwordless authentication process for web apps works well with both these platforms.