Overview

Cloud Secure Edge (CSE) leverages built-in certificate-based multi-factor authentication (MFA), providing elevated security without user disruption: an issued certificate is verified in the background, and users do not have to interact with any prompts.

In CSE’s MFA architecture, the user is cryptographically bound to their device for authentication, meaning that user credentials must match a specific device in order for users to authenticate.

Use this doc to understand how CSE’s MFA architecture connects various factors - including user credentials, managed certificates, user principal names (UPNs), device serial numbers, and device Trust Scoring - to strengthen authentication weak points.

How certificates work as an authentication method

Traditional MFA relies on proving something the user has (Possession) (e.g., a temporary code on a mobile device). In CSE’s case, Possession is proved by the user having a unique X.509 client certificate installed directly on their device. When a device is registered, CSE generates and manages a device certificate that is valid for 1 year. CSE automatically handles the renewal of this certificate over time, so IT teams do not need to manage certificate lifecycles.

In a certificate-based MFA flow, there is no aspect of a user entering a password in order for certificate verification to work; instead, a mutual TLS handshake is initiated between the server and the client, and the server certificate is verified first before the client certificate is presented. If the server certificate is valid, the client certificate uses a private key (installed on the user’s device in a private keychain) to authenticate. As a result, cert-based authentication is phishing-resistant because (1) server certificates are always verified by the certificate authority and (2) users never have to enter a password in order for authentication to work.

How CSE validates certificates during authentication flows

Here is the sequence of events that take place when a user attempts to access a protected resource:

1. Redirect to user’s IDP: The user initiates a connection to a resource. CSE's TrustProvider intercepts the request and redirects the user to their corporate Identity Provider (e.g., Entra ID, Okta, or LDAP).

2. Primary Authentication: The user logs into their IDP.

3. The Token Handoff: After the user enters the correct credentials, the IDP passes an authentication token back to CSE. This token contains the user's identity attributes, including their User Principal Name (UPN).

4. mTLS Check: CSE establishes a mutual TLS (mTLS) connection with the CSE client on the user's endpoint to inspect the device certificate.

5. The Cryptographic Binding Check: CSE's policy engine extracts the UPN tied to the device certificate and compares it against the UPN provided by the IDP token.

If a user successfully logs into their IDP, but they are using someone else’s credentials, the UPN on the device certificate will not match the UPN provided by the IDP token, and they will not be able to access the protected resource; CSE will instantly drop the connection and display a failure screen.

How certificates are cryptographically bound to the device

Device certificates cannot be exported to another machine. When a device’s certificate is minted, it is cryptographically bound to the physical hardware itself: it is bound to the device serial number and to a unique cryptographic thumbprint. Therefore, if a bad actor were to copy the certificate files to an unregistered machine, the hardware mismatch would cause the mTLS handshake to fail instantly.

How Trust Scoring manages device security posture in real-time

CSE’s MFA process goes beyond static hardware checks: Through device Trust Scoring, CSE enforces continuous authorization based on the real-time security posture of the endpoint.

During the mTLS handshake (and continuously while the session is active), the CSE client securely transmits Trust Factors to the policy engine. These factors analyze the device's posture, checking conditions such as:

• Is the operating system fully updated?

• Is the local firewall enabled?

• Is the hard drive encrypted?

• Are antivirus or EDR tools actively running?

• Is the device jailbroken or rooted?

Based on these Trust Factors, CSE calculates a dynamic Trust Level (e.g., High, Medium, Low, or Always Deny). If an employee successfully logs in from their trusted corporate laptop, but disables their firewall mid-session, their Trust Level drops dynamically and blocks access. CSE can immediately amend or revoke access to sensitive resources—even if the user and device identities are valid.

This guarantees that applications are only accessed by the right user, on the right hardware, and in the right security state.

How the issuing of the certificate is secured

Orgs using 3rd-party IDPs are already secured at the certificate issuing stage; Orgs using legacy directories, like on-premise LDAP, which require only a username and password, are often supplementing this with a separate MFA method, like a web application firewall (WAF) that applies an access rule to the corporate email.

Orgs using legacy directories who want to migrate over to CSE’s certificate-based MFA can do so securely using CSE’s Email One-Time Password (OTP) verification feature, built specifically for the initial device registration phase. When a user attempts to register a new device, CSE automatically triggers an email containing a secure OTP, sent directly to the user's corporate inbox. This creates an authentication bridge:

• The user must supply their username and password.

• The user must also prove possession of the corporate email inbox by retrieving the CSE One-Time Password (OTP); proof of possession of the corporate email leverages the org's existing MFA method.

By enforcing this OTP step during onboarding, CSE guarantees that the person requesting the certificate actually owns the identity.