Entra CBA 2: Authentication Methods and Per-User SKI Configuration

This article provides a high level overview of how to configure Certificate Based Authentication (CBA) on Microsoft Entra (formerly Azure Active Directory).  This article is useful as an initial configuration for test or small CBA roll out.  We recommend reviewing the following article as well:

https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-certificate-based-authentication

Configure Entra CBA Authentication Methods

Log in as Entra Global Administrator

Go to Entra ID

Go to Security

Go to Authentication Methods

Click on Certificate based Authentication

On the Settings Screen, set ENABLE to True

Select the user Group that will be using CBA for authentication

On the Configure Screen, set the Protection Level you want. Secupas Certificates are secured on a Smart Card or Token and further secured with a User PIN. Selecting Multi-factor Authentication means that the Certificate and PIN together are enough to meet the MFA requirement.  For Single-factor Authentication, the Card and PIN are considered a single factor, and this enables to use of additional factors.

On the Configure Screen for Username Binding, move SubjectKeyIdentifier to the top as Number 1 priority. The Secupas CMS registers the CBA Certificate using the SubjectKeyIdentifier.

Important:  Do NOT use the UPN for Username binding.  Use only the SubjectKeyIdentifier.

Bind a Certificate to a User Account (Set the SKI on the User)

Once CBA is enabled and the username binding rule is set to SubjectKeyIdentifier, each user who will sign in with a Secupas card must have the SKI of their card's certificate added to the certificateUserIds attribute on their Entra user object. Without this binding Entra cannot match the presented certificate to a user account and authentication will fail.

Step 1 — Obtain the SKI from the user's certificate

You will need the Subject Key Identifier (SKI) value from the certificate that was issued to the user's card. You can read it from the certificate file (.cer or .crt) on a Windows machine with either of the following:

From PowerShell:

(Get-PfxCertificate -FilePath "C:\path\to\cert.cer").Extensions | Where-Object {$_.Oid.Value -eq '2.5.29.14'} | ForEach-Object { $_.SubjectKeyIdentifier }

From the command line:

certutil -dump "C:\path\to\cert.cer"

Look for the Subject Key Identifier extension. The value will be a hex string, often displayed with colons or spaces between bytes — for example: 3F 41 3E E6 C3 93 B8 FB E8 76 5E 06 6F 57 51 6A 21 16 B2 83.

Step 2 — Format the SKI value for Entra

Entra requires the value in a very specific format. Take the SKI hex string and:

• Remove all spaces and colons
• Convert to uppercase
• Prepend the literal prefix X509:<SKI> (case-sensitive — capital X, capital S, capital K, capital I, literal angle brackets)

For the example above the final value is:

X509:<SKI>3F413EE6C393B8FBE8765E066F57516A2116B283

Important: Type or paste this value carefully. Curly "smart" quotes from Word, Outlook, or Teams will silently break the binding. Always paste as plain text and verify the value contains only straight ASCII characters.

Step 3 — Add the SKI value to the user's certificateUserIds attribute

This step requires the User Administrator role (or higher). Two methods are documented below — either one works. Pick whichever fits your workflow.

Method A — Entra admin center (GUI)

1. Sign in to entra.microsoft.com.
2. Navigate to Identity → Users → All users.
3. Select the user.
4. Select Edit properties on the user's overview page.
5. Scroll to the Authorization info section.
6. In the Certificate user IDs field, click Add and paste the formatted SKI value (e.g., X509:<SKI>3F413EE6C393B8FBE8765E066F57516A2116B283).
7. Click Save.

Method B — Microsoft Graph (for scripting or bulk operations)

Useful when onboarding many users at once. Send a PATCH request to the user endpoint:

PATCH https://graph.microsoft.com/v1.0/users/[e-mail]

With body:

{ "authorizationInfo": { "certificateUserIds": ["X509:<SKI>3F413EE6C393B8FBE8765E066F57516A2116B283"] } }

Required Graph permission: User.ReadWrite.All. This can be done interactively from Microsoft Graph Explorer or scripted with the Microsoft Graph PowerShell module.

Step 4 — Verify the binding

Confirm the value was stored correctly by running a GET request against the same user:

GET https://graph.microsoft.com/v1.0/users/[e-mail]?$select=authorizationInfo

The response should contain the SKI value with straight ASCII quotes and uppercase hex. If you see curly quotes (“ or ”) or lowercase hex in the stored value, delete the entry and re-add it carefully — these silently break the binding.

You can also confirm the user is now recognized as CBA-enabled by listing their authentication methods:

GET https://graph.microsoft.com/v1.0/users/[e-mail]/authentication/methods

An object of type #microsoft.graph.x509CertificateAuthenticationMethod should now appear in the list. If it does not, either the CBA policy is not scoped to this user, or the certificateUserIds value is malformed.

Multiple cards per user

The certificateUserIds attribute is multi-valued. If a user has a primary card and a backup card, add a separate X509:<SKI>… entry for each. The user can authenticate with either card.

Revoking a card

Because access is controlled by this per-user binding rather than by a CRL, card revocation is performed by removing the SKI value from the user's certificateUserIds attribute. Once removed, the card can no longer authenticate that user. Cards reported lost, stolen, or returned by departing employees should have their SKI value removed immediately.