Before any technical detail, it helps to understand the problem that certificates solve and why some organizations treat them as the strongest everyday sign-in method available.

The trouble with shared secrets

A password is a shared secret. You know it, and the system knows it, or at least knows a fingerprint of it. Because both sides know the secret, it has to travel from your fingers to the server on every sign-in, and it can be stolen at every point along that road. It can be copied from a sticky note, captured by malware, guessed by a program, leaked from another website where you reused it, or handed over by you to a page that only looks like the real one. Adding a second step helps a great deal, but many second steps, such as codes sent by message, can themselves be tricked out of people.

The certificate idea in one sentence

With a certificate, the secret never travels. Your device holds a private key that never leaves it. The server sends a fresh challenge, your device answers in a way that only the holder of that private key could, and the server checks the answer using a public certificate that is safe to share. Nothing a thief could reuse crosses the wire.

Who uses it and why

• Government and defense. Smart cards carried by staff are a long-standing standard, because they combine something you have with something you know.
• Regulated industries. Banks, health providers, and energy companies use certificates where strong, provable sign-in is required.
• Shared and kiosk machines. A card tap can be faster and safer than typing a long password on a shared keyboard.
• Managed devices. Companies place a certificate on each company laptop, so only known machines can reach sensitive systems.
• Machines and applications. Programs talking to other programs use certificates because there is no human to type anything.

Certificates come with a vocabulary that can feel intimidating. Each word is simple once you attach it to a picture.

Two more words deserve a note. X.509 is the name of the standard format that nearly all certificates follow, so when documentation says an X.509 certificate, it means an ordinary digital certificate. Mutual TLS is a secure connection in which both sides show certificates, not only the server, which is how machines usually authenticate each other.

A certificate is believable only because someone you already trust vouched for it. That vouching forms a chain.

Why not just trust every certificate?

Anyone can make a certificate. A certificate that says it belongs to the finance director is worthless unless a trusted party checked that claim and signed the document. The signature is a mathematical stamp that cannot be forged and breaks if anyone alters even one letter. A checker who knows the authority’s public key can verify the stamp.

The chain, link by link

• The root. The top authority signs its own certificate. A checker trusts it because it has been told to, by being placed in its list of trusted roots. This is called a trust anchor.
• The intermediate. The root signs a certificate for a second authority. That intermediate does the day-to-day signing of ordinary certificates.
• The leaf. The intermediate signs the certificate that belongs to a person, a device, or a server. This is the one presented at sign-in.

To check a leaf, the checker follows the signatures upward: the leaf was signed by this intermediate, the intermediate was signed by this root, and this root is on my trusted list. If every link verifies, and every certificate is within its dates and not revoked, the chain is valid.

flowchart TD
    ROOT["Root authority (trust anchor)"] -->|"signs"| INT["Intermediate authority"]
    INT -->|"signs"| LEAF1["Certificate for Priya"]
    INT -->|"signs"| LEAF2["Certificate for a laptop"]
    CHK["Checker's trusted list"] -.->|"already trusts"| ROOT
    

Notice why intermediates exist. The root’s private key is so valuable that organizations keep it offline in a locked room and use it rarely. The intermediate does the busy work. If an intermediate is ever compromised, it can be cancelled without throwing away the root and rebuilding trust from nothing.

Showing a certificate is not enough, because certificates are public. The real proof is demonstrating that you hold the matching private key.

The problem with showing alone

If a certificate were enough, anyone who copied your certificate could pretend to be you, since the certificate is designed to be shared. So the server also asks you to prove you hold the private key, without revealing the key. It does this with a challenge.

How the challenge works

sequenceDiagram
    participant D as Your device or card
    participant S as Server
    S->>D: "Please prove you hold the key, here is a random challenge"
    D->>D: "Sign the challenge with the private key"
    D-->>S: "Certificate plus signature"
    S->>S: "Verify signature with the public key in the certificate"
    S->>S: "Check chain, dates, and revocation"
    S-->>D: "Welcome"
    

Certificates are created and managed by a system called public key infrastructure, or PKI. Understanding it explains most real-world problems later.

The parts of a PKI

• Certificate authorities. The root and intermediates that sign certificates.
• Registration. The step where someone verifies who is requesting a certificate, such as checking an employee record.
• Enrollment. The process of generating a key pair, sending a request, and receiving the signed certificate.
• Templates and policies. Rules that decide what a certificate may contain and be used for.
• Revocation services. The lists or live services that report cancelled certificates.
• Lifecycle tools. Software that renews, replaces, and retires certificates automatically.

Where the request is born

The best practice is for the private key to be created on the device or card that will use it, so it never exists anywhere else. The device sends a request containing only the public key and the requested name. The authority checks the request, signs it, and returns the certificate. The private key was never in transit.

flowchart LR
    U["Person or device"] --> K["Creates key pair, private key stays inside"]
    K --> REQ["Sends request with public key"]
    REQ --> RA["Registration checks identity"]
    RA --> CA["Authority signs certificate"]
    CA --> RET["Certificate returned and installed"]
    

Who runs the authority?

Many organizations run their own private PKI, often built into their directory services, because they want full control over who gets certificates. Others buy certificates from commercial providers or use managed PKI services, which reduces the work of keeping the root safe. For sign-in to Okta, what matters is that Okta is told which authorities to trust, and that the certificates presented chain up to those authorities.

The safety of certificate sign-in depends heavily on where the private key is stored. Different homes offer very different protection.

Okta can use certificates in several different roles. Seeing the roles side by side prevents confusion later.

This guide focuses on the first two roles, where a person signs in with a certificate, and covers the device and application roles in later chapters. The last role, signing messages, is related but is more about trust between systems than about sign-in.

Why Okta sits in the middle

Without a central service, every application would need to learn how to read certificates, check chains, ask about revocation, and map names to users. With Okta in front, that work is done once. Applications simply trust Okta’s answer, whatever method the person used. This is the main reason organizations do certificate sign-in through an identity platform rather than application by application.

flowchart LR
    P["Person with card or device certificate"] --> O["Okta: checks certificate, maps to user, applies policy"]
    DV["Managed device with certificate"] --> O
    SV["Service with client certificate"] --> O
    O --> A1["Application 1"]
    O --> A2["Application 2"]
    O --> A3["Application 3"]
    

Here is the full picture of what is involved when a person signs in to Okta with a certificate, and the data that moves between the parts.

The components

• The person and their key. A smart card or device that holds the private key and the certificate.
• The browser and operating system. They offer the certificate to the server, ask the person to choose one if several exist, and prompt for the PIN.
• Okta. Receives the certificate, validates the chain, checks revocation, maps the certificate to a user, and applies policy.
• The certificate authority and revocation services. The place that signed the certificate and the place that answers whether it has been cancelled.
• The directory or user store. Where Okta finds the person that the certificate refers to.
• The application. Receives the result of the sign-in and trusts Okta’s statement.

sequenceDiagram
    participant U as Person
    participant B as Browser
    participant O as Okta
    participant R as Revocation service
    participant A as Application
    U->>A: "Open the application"
    A->>O: "Redirect to Okta to sign in"
    O->>B: "Request a client certificate"
    B->>U: "Choose certificate and enter PIN"
    U-->>B: "Card signs the challenge"
    B-->>O: "Certificate plus proof of key"
    O->>R: "Is this certificate still valid?"
    R-->>O: "Valid"
    O->>O: "Map certificate to a user and check policy"
    O-->>A: "Signed result: this is Priya"
    A-->>U: "Access granted"
    

What data moves where

Okta cannot decide on its own which authorities are trustworthy for your company. An administrator must tell it, and this choice is the foundation of everything else.

What you provide

You give Okta the public certificates of the authorities whose signatures it should accept. Usually this means the root certificate and the intermediate certificates that sit between the root and your users’ certificates. These are public documents, safe to share, and contain no secrets. Together they form the set of trust anchors for that configuration.

Why this step matters so much

• Too narrow. If you forget an intermediate, genuine users are refused because their chain cannot be completed.
• Too broad. If you trust a large public authority that issues certificates to anyone, then any stranger who obtains a certificate from it might be able to present one to your system. Narrow trust is safer.
• Out of date. When an authority is replaced or its certificate expires, users start failing on the day it happens unless the new certificate was added beforehand.

Good practice

• Trust only the authorities that your organization controls or has reason to rely on for people and devices.
• Keep a list of every trusted certificate with its expiry date, owner, and purpose.
• Add replacement authority certificates well before the old ones expire, so that both work during a changeover.
• Treat changes to the trust list as sensitive. Anyone who can add an authority can effectively create users.

flowchart TD
    ADM["Administrator uploads authority certificates"] --> TL["Trusted list in Okta"]
    INC["Incoming user certificate"] --> V{"Chain ends at a trusted authority?"}
    TL --> V
    V -- "Yes" --> NEXT["Continue to date and revocation checks"]
    V -- "No" --> REJ["Reject: untrusted issuer"]
    

A valid certificate only proves that some holder exists. Okta must still decide which person in its directory that certificate refers to.

The mapping idea

Inside the certificate are fields that identify the holder, such as an email address, a sign-in name in the subject alternative name, or a unique employee identifier. Inside every Okta user profile are fields too. A mapping rule says which certificate field should match which profile field. When the values agree, the certificate is linked to that user for the sign-in.

Choosing the right field

Common mapping problems

• No match. The value in the certificate does not exist in any profile, perhaps because of spelling or format.
• More than one match. Two profiles share the same value, so the sign-in is ambiguous and is refused.
• Wrong match. A loosely chosen field maps the certificate to the wrong person, which is a security failure and not just an inconvenience.
• Drift. Profiles change over time, and the mapping silently stops working for people whose fields changed.

flowchart TD
    CERT["Certificate fields"] --> RULE["Mapping rule"]
    RULE --> LOOK["Search Okta profiles"]
    LOOK --> N{"How many matches?"}
    N -- "Exactly one" --> OK["Sign-in continues as that user"]
    N -- "None" --> NO["Fail: user not found"]
    N -- "More than one" --> AM["Fail: ambiguous"]
    

Now that the pieces are known, here is the whole sign-in as Okta experiences it, with the checks in the order they happen.

stateDiagram-v2
    [*] --> Presented
    Presented --> KeyProven: "challenge signed"
    Presented --> Failed: "no key proof or wrong PIN"
    KeyProven --> ChainOK: "chain valid"
    KeyProven --> Failed: "untrusted issuer"
    ChainOK --> NotRevoked: "dates and revocation pass"
    ChainOK --> Failed: "expired or revoked"
    NotRevoked --> Mapped: "exactly one user"
    NotRevoked --> Failed: "no match or several"
    Mapped --> PolicyOK: "policy allows"
    Mapped --> Failed: "policy denies"
    PolicyOK --> [*]
    Failed --> [*]
    

Certificates last for months or years, but circumstances change in days. Revocation is how the system learns that a still-valid-looking certificate must no longer be trusted.

Why revocation is needed

• A smart card is lost or stolen.
• A person leaves the company or changes role.
• A laptop is retired or compromised.
• A private key may have been copied.
• An authority discovers that certificates were issued by mistake.

Two ways to check

The central difficulty: soft fail versus hard fail

What should happen if the revocation service cannot be reached? Refusing everyone is safe but can lock out the whole company when a network link breaks. Allowing everyone keeps work moving but means that a stolen card still works during the outage. This choice, often called hard fail versus soft fail, is one of the most important decisions in a certificate deployment. Many organizations choose to refuse for high-risk applications and to allow, with extra monitoring, for lower-risk ones.

flowchart TD
    C["Certificate passes chain and date checks"] --> Q["Ask revocation source"]
    Q --> R{"Answer received?"}
    R -- "Yes, valid" --> OK["Continue"]
    R -- "Yes, revoked" --> DENY["Deny sign-in"]
    R -- "No answer" --> P{"Policy for unknown status"}
    P -- "Hard fail" --> DENY
    P -- "Soft fail" --> OKW["Continue and raise an alert"]
    

Having certificate sign-in available is not the same as requiring it. Policies decide who must use it, for which applications, and under what conditions.

The levers

• Who. All employees, a group such as administrators, contractors, or people on specific devices.
• What. Particular applications, or all of them. Sensitive systems often get stricter rules than ordinary ones.
• Where. Offices, trusted networks, or any location. Location can raise or relax requirements.
• Which device. Managed laptops versus personal ones.
• How strong. Certificate alone, certificate with a PIN, or certificate plus another factor.
• What if it fails. A fallback method, a help desk process, or no fallback at all.

flowchart TD
    REQ["Sign-in request"] --> A{"Sensitive application?"}
    A -- "Yes" --> B{"Managed device with certificate?"}
    B -- "Yes" --> C["Allow with certificate and PIN"]
    B -- "No" --> D["Deny or step up"]
    A -- "No" --> E["Allow with standard strong factor"]
    

One of the strongest reasons to use certificates is that they resist the most common attack on human sign-in: the convincing fake page.

How a phishing attack normally works

An attacker sends a message with a link to a page that looks exactly like the real sign-in page. The victim types a password, and possibly a code, into the fake page, and the attacker immediately uses them on the real site. Any secret the victim can be persuaded to type or read out can be stolen this way.

Why certificates behave differently

• Nothing to type. The private key never appears on screen and cannot be read out or pasted.
• The proof is tied to the real site. During the secure connection, the signature covers details of that specific connection, so a response made for a fake site is useless on the real one.
• The key refuses to leave. A hardware-protected key cannot be copied by a malicious page or program.

The limits

• If the fallback is a password, attackers will simply target the fallback.
• Malware on the device may use the key while the card is plugged in and unlocked.
• A person can be tricked into approving a PIN prompt they did not start.
• Software-stored or exported keys can be copied.

sequenceDiagram
    participant V as Victim
    participant F as Fake site
    participant R as Real site
    V->>F: "Opens look-alike page"
    F->>R: "Tries to sign in as the victim"
    R->>F: "Challenge tied to the real connection"
    F->>V: "Asks the card to answer"
    V-->>F: "Card signs, but for the fake connection"
    F->>R: "Forwards the signature"
    R-->>F: "Rejected: does not match this connection"
    

Certificates can prove not only who a person is but also which machine they are using. That second question matters more than many organizations realize.

The device question

A correct password from a stranger’s unmanaged laptop in another country is a very different event from the same password on a company laptop in the head office. A device certificate lets the organization tell them apart. When a company installs a certificate on each machine it manages, the presence of that certificate on a sign-in attempt is a strong hint that the machine is known, healthy, and governed by company rules.

How it typically works

• A device management system issues each managed laptop or phone a certificate, with the private key held in the device’s protected chip.
• When the user signs in, the device offers the certificate during the secure connection.
• Okta checks the chain and revocation, and uses the result as a signal in policy: managed device or not.
• Policy then allows, blocks, or steps up the sign-in according to the application’s sensitivity.

flowchart LR
    MDM["Device management issues certificate"] --> DEV["Managed laptop with protected key"]
    DEV -->|"Sign-in with device certificate"| OK["Okta policy sees managed device"]
    PER["Personal unmanaged laptop"] -->|"No device certificate"| OK2["Okta policy sees unmanaged device"]
    OK --> ALLOW["Allow sensitive apps"]
    OK2 --> LIMIT["Limit or block sensitive apps"]
    

Not every sign-in involves a person. Programs also need to prove who they are, and certificates are a natural fit.

Why programs use certificates

A program that connects to a service every few seconds cannot type a password, and a shared secret stored in its configuration is a standing risk: copied, logged, or leaked, it works for anyone who finds it. A certificate with a protected private key lets the program prove itself through the same challenge idea described earlier. The secret does not travel, and the certificate can be cancelled without changing anything for other clients.

Common patterns

• Mutual TLS. Both sides present certificates when the secure connection starts, so each knows who the other is.
• Certificate-based client authentication for tokens. A program proves its identity with a certificate or a signed statement when requesting access tokens from Okta, instead of sending a shared secret.
• Signed messages. Systems sign sign-in assertions or requests, and the receiver checks the signature against a known certificate.

Things to plan for

• Short certificate lifetimes with automated renewal, because forgotten expiry dates take services down.
• A clear owner for every certificate used by a service.
• Safe places to keep private keys, such as managed secret stores or hardware modules.
• Inventory, so you know where every certificate is used.

sequenceDiagram
    participant S as Service
    participant O as Okta
    participant API as Protected API
    S->>O: "Request access, prove identity with certificate"
    O->>O: "Verify chain, dates, and registered client"
    O-->>S: "Short-lived access token"
    S->>API: "Call with token"
    API-->>S: "Data"
    

Much of the day-to-day experience of certificate sign-in is decided on the person’s own machine, not in Okta. Most support calls begin here.

What the person’s machine must do

• Find the certificate. The operating system keeps certificates in a store, and smart cards expose theirs through middleware, a small piece of software that lets the system talk to the card.
• Offer it to the browser. When Okta asks for a certificate, the browser lists matching ones and may ask the person to choose.
• Ask for the PIN. Card-based keys normally require a PIN for each use or for a short period.
• Sign the challenge. Either the card or the secure chip does the mathematics and returns the result.

The usual hiccups

flowchart LR
    CARD["Smart card or secure chip"] --> MW["Middleware or system key store"]
    MW --> BR["Browser"]
    BR -->|"Secure connection with client certificate"| OK["Okta"]
    

A certificate has a life with a beginning and an end. Managing that life is the largest ongoing task in any certificate program.

Why expiry is a two-edged sword

Shorter lifetimes limit the damage from a stolen key and force regular cleanup. But shorter lifetimes also mean more renewals, and every renewal is a chance to fail. Organizations that choose short lifetimes must automate renewal. Those that cannot automate usually choose longer lifetimes combined with strong revocation.

stateDiagram-v2
    [*] --> Requested
    Requested --> Issued: "identity verified"
    Issued --> InUse: "installed"
    InUse --> Renewed: "near expiry"
    Renewed --> InUse
    InUse --> Revoked: "lost or compromised"
    InUse --> Expired: "not renewed in time"
    Revoked --> [*]
    Expired --> [*]
    

Certificates must follow the same people lifecycle as every other access. The risk is that their separate life makes them easy to forget.

Joiners

New employees need an identity record, a way to prove who they are before receiving a card or device certificate, and a safe first-day path. A common problem: the new hire cannot sign in to collect the certificate because they do not yet have a certificate. Plan an initial bootstrap, such as in-person issuance or a one-time enrollment link delivered through a verified channel.

Movers

When someone changes role or name, check whether their certificate contains values that have now changed. If the mapping field was based on a name or email that was altered, the mapping may break at the moment of the change, causing a lockout that appears unrelated.

Leavers

• Deactivate the Okta user so that no certificate can sign in as them.
• Revoke their certificates at the authority, so that the cancellation also stops use in systems outside Okta.
• Collect smart cards where possible, and wipe or revoke device certificates when machines are returned.
• Check for services or scripts that used the person’s certificate.

flowchart TD
    HR["HR event"] --> J{"Type of event"}
    J -- "Joiner" --> I1["Create user, issue certificate after identity check"]
    J -- "Mover" --> I2["Review mapping fields, renew if needed"]
    J -- "Leaver" --> I3["Deactivate user, revoke certificates, collect card"]
    

A good rollout is boring. People keep working, problems are found early, and the old method disappears only when nobody needs it.

gantt
    title A certificate rollout outline
    dateFormat YYYY-MM-DD
    axisFormat %b
    section Preparation
    PKI and data readiness :a1, 2026-02-02, 28d
    Test configuration :a2, after a1, 14d
    section Rollout
    Pilot group :b1, after a2, 21d
    Wave one :b2, after b1, 21d
    Wave two :b3, after b2, 28d
    section Hardening
    Remove weaker fallbacks :c1, after b3, 21d
    

Certificate sign-in quietly depends on several pieces of infrastructure. When one fails, the symptom is often a sign-in failure with no obvious link.

The inspection trap

Some security appliances open secure connections, look inside, and re-establish a new one on the other side. This is called inspection. In the middle, the device speaks for the client, so the client’s certificate and proof of key never reach the server. Certificate sign-in then fails in strange ways only on certain networks. The cure is to exclude the identity provider’s address from inspection, a change that must be agreed with the network team.

flowchart LR
    U["User device"] --> P["Inspecting proxy"]
    P -->|"New connection, no client certificate"| O["Okta"]
    U -.->|"Direct connection keeps certificate"| O
    

Certificates are strong, but they are not magic. Knowing how they can fail guides where to put effort.

The principle: protect issuance as much as sign-in

Sign-in verifies a certificate, but the certificate was only as trustworthy as the process that issued it. If an attacker can persuade the help desk to issue a certificate in someone else’s name, the cryptography will faithfully authenticate the wrong person. Identity checks at issuance, approval for sensitive roles, and logging of every issuance are as important as any setting in Okta.

flowchart TD
    ISS["Strong issuance checks"] --> KEY["Hardware-protected key"]
    KEY --> TRUST["Narrow trusted list"]
    TRUST --> MAP["Unique mapping"]
    MAP --> REV["Fast revocation"]
    REV --> MON["Monitoring and alerts"]
    

A certificate program that is not watched slowly decays. A handful of signals will tell you early when something is going wrong.

What to watch

A troubleshooting order that works

flowchart TD
    F["Sign-in failed"] --> A{"Certificate arrived?"}
    A -- "No" --> A1["Client, reader, or network path"]
    A -- "Yes" --> B{"Chain trusted?"}
    B -- "No" --> B1["Trusted list or intermediates"]
    B -- "Yes" --> C{"In date and not revoked?"}
    C -- "No" --> C1["Renew, replace, or fix status service"]
    C -- "Yes" --> D{"Mapped to one active user?"}
    D -- "No" --> D1["Fix mapping data"]
    D -- "Yes" --> E["Review policy"]
    

A short list of failures causes most certificate outages. Rehearse them so that the real thing is only a routine.

sequenceDiagram
    participant M as Monitoring
    participant E as On-call engineer
    participant O as Okta
    M->>E: "Alert: sign-in failures rising"
    E->>O: "Check failure reasons"
    O-->>E: "Reason: untrusted issuer"
    E->>O: "Add the renewed authority certificate"
    O-->>E: "Sign-ins recovering"
    E->>M: "Confirm alert clears and record the cause"
    

Certificate sign-in works for ten people and works for a hundred thousand, but different things matter at each size.

What grows with size

• Revocation traffic. Every sign-in may trigger a status check. A very large workforce arriving at nine in the morning produces a burst of checks that the status service must absorb.
• List size. Published revocation lists grow with the number of cancelled certificates and can become slow to download and parse.
• Helpdesk load. Lost cards, forgotten PINs, and replaced devices scale directly with headcount.
• Inventory. More certificates mean more expiry dates to track, and more services depend on them.
• Issuance throughput. Onboarding waves or device refreshes can overwhelm an authority that was sized for steady trickles.

Ways to keep it healthy

• Prefer live status checks with caching for busy systems, and keep lists small by using several narrower authorities.
• Run revocation services on more than one server in more than one place.
• Automate renewals and enrollment so people are not queuing at a desk.
• Give the help desk self-service tools for PIN resets and card replacement requests.
• Maintain an inventory that records owner, purpose, expiry, and where each certificate is used.
• Stagger scheduled renewals, so thousands of certificates do not all expire on the same day.

flowchart LR
    U1["Morning sign-in burst"] --> OK["Okta"]
    OK --> C["Status cache"]
    C -->|"Cache hit"| OK
    C -->|"Cache miss"| S1["Status service 1"]
    C -->|"Cache miss"| S2["Status service 2"]
    

These patterns have proved themselves in many organizations. Adapt them to your own needs.

flowchart TD
    ID["Strong issuance"] --> HW["Hardware-protected key"]
    HW --> TR["Narrow trusted authorities"]
    TR --> MP["Unique mapping"]
    MP --> POL["Policy: person plus device"]
    POL --> RV["Revocation with defined rule"]
    RV --> LC["Automated lifecycle"]
    LC --> MN["Monitoring and tested break-glass"]
    

These habits look convenient and cause lasting trouble. Learn to spot them early.

Every choice gives something up. Naming the trade-offs makes decisions deliberate.

The main trade-offs

Best practices

• Decide which key homes are acceptable, and refuse exportable keys for sensitive roles.
• Trust only authorities you control or have vetted, and inventory them.
• Choose a unique, stable mapping field and verify that data before launch.
• Define the rule for unknown revocation status per application risk.
• Combine person and device assurance for the most sensitive systems.
• Protect issuance with real identity checks and approvals.
• Automate renewal, and keep an expiry calendar with early alerts.
• Connect certificate actions to joiner, mover, and leaver processes.
• Monitor failure reasons, trust changes, and revocation availability.
• Pilot, expand in waves, and remove weaker methods last.
• Keep and test emergency access.

Common mistakes

• Forgetting to include an intermediate authority.
• Using names or emails that change as mapping fields.
• Letting software and middleware update on all machines at once.
• Ignoring clocks and time synchronization.
• Forgetting that inspecting proxies can break client certificates.
• Deactivating a user but not revoking the certificate.
• Leaving the emergency account untested.

quadrantChart
    title Choosing where to require certificates
    x-axis Lower sensitivity --> Higher sensitivity
    y-axis Few users --> Many users
    quadrant-1 Phased rollout with strong policy
    quadrant-2 Broad rollout with automation
    quadrant-3 Optional or later
    quadrant-4 Immediate strict policy
    Administrators: [0.95, 0.1]
    Finance staff: [0.75, 0.4]
    All office staff: [0.4, 0.85]
    Kiosk workers: [0.5, 0.6]
    Public help pages: [0.1, 0.5]
    

This picture is a way of thinking rather than a measurement. Small groups with very sensitive access are easy to manage and worth protecting first. Large groups need automation and support before the policy tightens. Low-sensitivity areas may never need certificates at all.

Applications rarely see the certificate at all. They see Okta’s statement about the person, and that statement can include how the person proved themselves.

The handover

Once Okta has validated the certificate, mapped it to a user, and applied policy, it ends the conversation with the application using a standard sign-in protocol. The application receives a signed message saying who the person is, plus details such as the time of sign-in and how strong the proof was. The application checks Okta’s signature, not the certificate. This is a big benefit: dozens of applications gain certificate-strength sign-in without learning anything about certificates.

Carrying the strength forward

• Method information. Messages can record that a hardware-backed certificate and a PIN were used, so the application knows more than just a name.
• Assurance level. Some applications demand a higher level for sensitive actions, such as approving a payment, and can ask Okta to prove the person again.
• Session age. Applications may refuse old sessions for risky actions and send the person back through a fresh certificate check.

sequenceDiagram
    participant U as Person
    participant A as Application
    participant O as Okta
    U->>A: "Open sensitive screen"
    A->>O: "Need a recent strong sign-in"
    O->>U: "Present the card again"
    U-->>O: "Certificate proof"
    O-->>A: "Signed statement: strong sign-in just now"
    A-->>U: "Screen opens"
    

Every certificate carries the same kinds of fields. Knowing which ones matter prevents the most common design errors.

Strength of the mathematics

Certificates use algorithms with a key size or curve. Older, smaller choices become weak over time as computers improve. Most organizations follow current guidance from national security bodies, retire old algorithms on a schedule, and keep the ability to change algorithms without redesigning everything. This flexibility is sometimes called crypto agility. When planning a program that will last a decade, assume that today’s defaults will one day need replacing.

flowchart TD
    CRT["Certificate"] --> ID["Who: subject and alternative names"]
    CRT --> TR["Who vouched: issuer and signature"]
    CRT --> TM["When: validity dates"]
    CRT --> PU["For what: key usage"]
    CRT --> KY["Strength: public key and algorithm"]
    CRT --> RV["Cancelled? revocation pointers"]
    

Signing in is not a one-time event. How long the session lasts and when it asks again are part of the security design.

Levels of assurance

Not every sign-in proves the same amount. A hardware card with a PIN, used just now, in front of a managed device, is very strong. A software certificate on an unmanaged laptop, used yesterday, is weaker. Policy can treat these differently, giving ordinary access to the weaker proof and sensitive access only to the stronger.

Step-up

Step-up means asking for stronger or fresher proof at the moment it matters. A person who signed in with a certificate in the morning may be asked to tap their card again before approving a large transfer or changing security settings. This keeps daily work smooth while protecting the few actions where harm would be greatest.

Session length and card removal

• Shared workstations benefit from short sessions that end when the card is removed.
• Personal managed laptops can have longer sessions with periodic rechecks.
• Privileged consoles should have short sessions and re-prompt for sensitive actions.
• Idle timeouts protect against forgotten unlocked screens.

stateDiagram-v2
    [*] --> SignedOut
    SignedOut --> Standard: "certificate sign-in"
    Standard --> Elevated: "step-up with card and PIN"
    Elevated --> Standard: "timer expires"
    Standard --> SignedOut: "idle timeout or card removed"
    Elevated --> SignedOut: "sign out"
    

Many organizations adopt certificates because regulations or contracts require strong authentication. Being able to prove it matters as much as doing it.

What auditors usually ask

• Which systems require certificate-based sign-in, and which still allow weaker methods?
• How are keys protected, and can they be exported?
• How is identity checked before a certificate is issued, and who approved it?
• How quickly are lost or compromised certificates revoked?
• Who can change the trusted authority list and mapping rules, and are changes reviewed?
• How long are sign-in and issuance logs kept, and are they protected from tampering?

Evidence worth keeping

flowchart LR
    ISS["Issuance records"] --> EV["Evidence store"]
    REV["Revocation records"] --> EV
    SIG["Sign-in logs"] --> EV
    CHG["Configuration changes"] --> EV
    EV --> AUD["Audit review and reports"]
    

Certificate sign-in has many ways to fail, so a short, deliberate test plan is worth far more than hope.

Making testing practical

• Create a small private test authority and issue deliberately faulty certificates for these cases.
• Keep test accounts in a separate group that cannot reach real data.
• Record screenshots and log lines for each case so the help desk can recognize them later.
• Repeat the tests after every change to trust, mapping, or policy.

flowchart LR
    TA["Test authority"] --> GOOD["Good certificates"]
    TA --> BAD["Deliberately faulty certificates"]
    GOOD --> RUN["Run the test list"]
    BAD --> RUN
    RUN --> RES["Compare with expected results"]
    RES --> DOC["Update help desk guide"]
    

The best-designed system fails if people do not understand it. A little attention to the human side prevents most of the pain.

What users need to know

• What the card or certificate is, and why it replaces the password for them.
• How to choose the right certificate when several appear, and what the PIN prompt looks like.
• What to do if the card is lost, damaged, or forgotten, and how to reach the hotline at any hour.
• That the PIN is personal and must never be shared or written on the card.
• Why they should never approve a prompt they did not start.

What the help desk needs

• A decision tree matching the troubleshooting order from earlier, with screenshots.
• The ability to verify identity strongly before resetting a PIN or issuing a replacement.
• A way to see the failure reason for a user’s recent attempts.
• Clear escalation to the identity team for mapping and trust problems.

Accessibility and fairness

Gloved hands, shared stations, people with limited dexterity, remote workers without readers, and staff who travel are all real situations. Offer reasonable alternatives that are strong in their own way, and avoid leaving a weak backdoor as the easy default for the people who find the main path difficult.

flowchart TD
    CALL["User contacts help desk"] --> V{"Identity verified strongly?"}
    V -- "No" --> HOLD["Do not change anything"]
    V -- "Yes" --> T{"Card lost or damaged?"}
    T -- "Yes" --> REV["Revoke, issue replacement"]
    T -- "No" --> TS["Follow the troubleshooting order"]
    

To bring everything together, here is an invented organization and its certificate strategy. The company, numbers, and names are made up for teaching.

The company

Harborview Health is a fictional hospital network with 9,000 staff in five hospitals and forty clinics. Clinicians move between shared workstations all day, often with gloved hands and in a hurry. Regulators require strong authentication for access to patient records. Passwords were typed forty times a shift, written on notes beside screens, and reset constantly. The company already ran a private authority for its directory, and each clinician carried a badge with a chip.

The design

flowchart LR
    BADGE["Staff badge with chip"] --> WS["Shared workstation reader"]
    WS --> OK["Okta"]
    OK --> ST["Two status services"]
    OK --> DIR["Directory and user profiles"]
    OK --> EMR["Patient record application"]
    LAP["Managed laptop certificate"] --> OK
    

How the first nine months went

The pilot in one clinic found that eleven staff had two accounts with the same employee identifier because of an old merger. Mapping would have been ambiguous, so the data was cleaned before the pilot widened. The second finding was a surprise: one hospital’s network inspection device removed the client certificate, so badge sign-in worked in every building except that one. Excluding Okta from inspection solved it within a day, and the lesson was added to the rollout checklist.

In month five, the first issuing authority certificate was due to expire in ninety days. The expiry alert fired, the renewed certificate was added alongside the old one, and nobody noticed anything. In month seven, a clinician lost a badge on a train. The hotline revoked the certificate in under ten minutes, and the log showed no sign-in attempts afterward. Typing of passwords dropped sharply, and tickets for password resets fell by about seventy percent.

Short answers to questions that come up often. Okta features, limits, and menu names change over time, and some depend on your plan, so confirm exact details in the current Okta documentation.

Certificate-based authentication replaces a secret you type with a proof you cannot be tricked into giving away.