What you'll learn: a current, practical path to deploy just‑in‑time (JIT) access for SSH and RDP in September 2026. This update adds developments from the past year—token exchange patterns, device‑bound tokens, HSM/MPC signing options, and cloud broker integrations—so zero‑trust teams can implement a secure, auditable, and usable JIT workflow right now.

Who this is for: security engineers, platform teams, and zero‑trust architects who operate bastions, signing CAs, or session brokers and want concrete, implementable guidance tuned to 2026 best practices.

Prerequisites and context

Before you start: you should have an enterprise OIDC identity provider (Okta, Azure AD, Google Workspace, Ping, or similar), working CI/CD and configuration‑management tooling, a SIEM/logging pipeline, and an operations playbook for incident response. Familiarity with OpenSSH certificates, Windows RDP administration, and policy engines (OPA/Rego or commercial PDPs) is expected.

Why this still matters in 2026: credential theft and misuse remain top attack vectors for lateral movement. Short‑lived, identity‑bound credentials limit exposure and—when combined with strong claims from an IdP, a policy decision point (PDP), and centralized telemetry—provide both protection and traceability. Since the original July 2026 piece, adoption has continued to accelerate and tooling has matured: token exchange patterns and device trust signals are now common, cloud session brokers have deeper integrations, and hardware/MPC protections for signing keys are widely available. This guide updates recommended architectures and operational controls accordingly.

Updated architecture overview

A production‑ready JIT access architecture in 2026 includes:

  • Identity Provider (IdP): OIDC provider issuing short‑lived tokens and device posture claims (examples: Azure AD, Okta, Google Workspace, Ping).
  • Signing CA/service: issues OpenSSH user certs and TLS client certs after validating OIDC tokens or exchanged tokens. Implemented via step‑ca, HashiCorp Vault PKI, Teleport, or a managed/internal service. Protect signing keys in HSM or via multi‑party computation (MPC).
  • Policy Decision Point (PDP): evaluates attributes—groups, MFA, device posture, approval state, geo/time—and returns allow/deny plus constraints. Use OPA/Rego or a commercial PDP integrated with your IdP and SIEM.
  • Bastion/session broker / ZTNA connector: validates certs, proxies sessions, records telemetry, and enforces denylists. Cloud session brokers (AWS Systems Manager Session Manager, Azure Bastion, Google Cloud IAP) and vendors (Teleport, Teleport-like brokers, Cloudflare Access) are common.
  • Telemetry and audit pipeline: immutable issuance logs, session recordings/metadata, IdP events, and PDP decisions forwarded to SIEM/EDR for detection and post‑incident forensics.

High‑level flow (modernized)

  1. User authenticates at the IdP with strong auth (FIDO2/passkey or MFA). IdP issues a short‑lived id_token and a short‑lived access_token or supports token exchange (RFC 8693).
  2. Client (CLI, agent, or browser) performs an OIDC token exchange to mint a scoped, audience‑restricted token for the signing CA (recommended). This reduces token replay risk and avoids exposing longer‑lived id_tokens to backend services.
  3. The client submits a public key/CSR plus the exchanged token to the signing CA. The CA validates the token, then calls the PDP with user identity and context (device_posture, MFA, IP, approval state).
  4. If PDP allows, the CA signs a short‑lived certificate (typical TTL 5–20 minutes; longer only with explicit approvals) and returns it to the client.
  5. User connects to bastion or host trusting the CA; session is proxied/recorded and telemetry is emitted. Certificates expire automatically; for urgent revocation use broker denylists or ephemeral account deletion workflows.

Step‑by‑step deployment (practical, Sept 2026)

1. Plan policy and governance

  1. Inventory who needs JIT access and classify use cases: admin tasks, automation, third‑party contractors, emergency break‑glass. Map required principals and acceptable TTLs. Suggested default TTLs in 2026: 5–15 minutes for interactive admin, 15–60 minutes for approved maintenance windows; automation tokens may be longer but should be rotated automatically.
  2. Define policy attributes: IdP groups, MFA (prefer FIDO2/passkeys for admins), device posture (endpoint security signals from EDR or device trust), geolocation/IP restrictions, and approval prerequisites for higher privileges.
  3. Create retention and legal hold rules for issuance logs and recordings (WORM storage where required). Ensure PDP policy versions are versioned and auditable.

Why: precise policies allow the PDP to make deterministic, auditable decisions and reduce helpdesk friction when policies are explicit and documented.

2. Choose and harden your CA

  1. Pick a CA solution that supports OpenSSH user certificates and client TLS certs, validates OIDC tokens, and integrates with your PDP and logging pipeline. Options include smallstep/step‑ca, HashiCorp Vault, Teleport, or a custom signing service with a protected signing key.
  2. Protect signing keys: use an HSM or cloud KMS with strict access controls. For higher assurance, adopt MPC or threshold signing services to avoid a single signing key compromise; providers offering MPC signing became more common in 2025–2026.
  3. Implement key rotation and key‑availability plans. Rotate signing keys on a schedule (e.g., quarterly for cluster CAs) and publish transition plans to hosts to maintain trust during rotations.

Why: the signing CA is the central privilege gate—protecting it is critical. MPC reduces single‑point‑of‑failure risk; HSMs provide attestation and audited use.

3. Integrate with your IdP (use modern token patterns)

  1. Configure the IdP to emit required claims (sub, groups, email, device posture or device_id if available). Prefer short token lifetimes (id_token/access_token lifetimes of minutes).
  2. Use OIDC Token Exchange (RFC 8693) so clients exchange an initial token for a narrowly scoped token whose audience is the CA service. This minimizes exposure of tokens and prevents replay across services.
  3. Require FIDO2/passkeys or hardware MFA for admin groups where possible; use conditional access policies to enforce device trust and session risk evaluation.

Why: exchanged, audience‑restricted tokens reduce attack surface; strong authentication and device claims make PDP decisions more reliable.

4. Implement the signing workflow

  1. Design the signing API to accept a public key/CSR and an exchanged token. Authenticate the request using the token audience and signature.
  2. Validate the token against the IdP jwks or via token introspection. Extract claims and contextual attributes.
  3. Call the PDP with a full context bundle: user identity, groups, MFA method and timestamp, device posture, requestor IP, requested principals, and requested TTL. PDP returns allow/deny and constraints (max TTL, permitted principals).
  4. If allowed, sign an OpenSSH user certificate with the constrained TTL and principals. Include meaningful key IDs (e.g., user@idp.example.com;request-id) and record the issuance event in an append‑only audit log.

Example CA attributes to set: key id (user@idp.example.com;policy=v2), principals (username, role:ops), valid-before (epoch + TTL), and extensions (permit‑pty, source‑addresses where applicable).

5. Configure hosts and bastions to trust the CA

  1. OpenSSH hosts: install CA public key in TrustedUserCAKeys and use AuthorizedPrincipalsCommand to map certificate principals to local accounts or roles. Use configuration management to enforce consistency.
  2. Bastion/session broker: require client certs or broker token validation. Brokers should consult a live denylist before allowing sessions and record session metadata (serial, principal, source IP) to SIEM. Use network controls to prevent direct exposure of RDP/SSH ports.
  3. Cloud providers: integrate with AWS Systems Manager Session Manager, Azure Bastion, or Google Cloud IAP where applicable; ensure session brokers are configured to accept your CA or use provider‑native ephemeral credential features.

Why: centralizing trust at the bastion and host level enables fast revocation via denylists and consistent policy enforcement.

6. RDP options—current practical approaches

Since native SSH‑style certs for RDP are still not universal, practical options in 2026 include:

  • Session broker with ephemeral local accounts: broker authenticates user via OIDC, creates a short‑lived local Windows account or creates a temporary Kerberos ticket via Windows APIs, provisions credentials via management API, and deletes the account after session end. Ensure the broker runs in a hardened environment and emits full audit trails.
  • RDP over SSH or TLS tunnel: use a trusted SSH bastion (with SSH certs) to tunnel RDP traffic. This reuses your existing SSH cert trust and session recording infrastructure.
  • Cloud provider session brokers: use AWS SSM, Azure Bastion, or Google Cloud IAP session broker features to avoid exposing RDP. Confirm IdP integrations and whether the provider supports your required device posture and audit controls.

Why: brokers reduce the need for permanent Windows accounts and centralize session recording and denylist enforcement.

Policy enforcement and PDP design (updated)

Design PDP rules that are explicit, versioned, and include decision provenance. Example rules in 2026:

  • Users in group "infra-admins" with FIDO2 authentication and device_posture >= 90 receive a 15‑minute SSH cert for production principals between 08:00–20:00 UTC.
  • Contractors require active owner approval via the IdP workflow, are limited to non‑prod principals, and receive a single 30‑minute cert per approval session.
  • Requests from IPs flagged as high risk or with stale posture data are denied or escalated to a human approval flow.

Best practice: include policy_version and policy_hash in PDP responses and record them in issuance logs for forensic traceability.

Telemetry, auditing and detection (modernized)

Emit and correlate these immutable events:

  • IdP authentication events (auth type, time, device assertion).
  • Token exchange events (who exchanged what to mint a CA‑audience token).
  • Certificate issuance logs: requestor, principals, TTL, PDP decision and policy version, signing key id.
  • Session metadata and recordings (source IP, bastion instance, target host, serial numbers).
  • Anomalies: simultaneous issuance from multiple geos, immediate failed session patterns, or unusual TTLs.

Operationalize detection rules in SIEM/EDR and retain issuance logs for compliance and incident response. Consider WORM storage for critical logs and use cryptographic signing of audit records where your compliance regime requires non‑repudiation.

Revocation, TTL tradeoffs and emergency access

OpenSSH certificates do not have CRLs like X.509. Recommended practice in 2026:

  • Favor short TTLs rather than runtime revocation for routine operations. Short windows reduce operational complexity.
  • Maintain a real‑time denylist consulted by bastions and brokers for urgent revocation; ensure the denylist is highly available and under strict access controls.
  • Define a break‑glass process that issues longer certificates only after multi‑party approvals and heightened monitoring. Log and alert on any break‑glass issuance immediately.

Migration checklist (from long‑lived keys/accounts)

  1. Inventory all long‑lived SSH keys and Windows accounts. Tag stale or shared credentials and create removal plans.
  2. Pilot CA trust with a small cohort. Run pilot hosts that accept both legacy and cert‑based auth to measure UX and recording reliability.
  3. Automate removal of legacy keys (e.g., replace authorized_keys with an AuthorizedKeysCommand that rejects legacy methods after cutoff).
  4. Onboard teams with training and ergonomic tooling (CLI agent, desktop helper for cert requests, SSO‑linked browser UI).
  5. Gradually enforce the new flow in network controls and bastion policies; deprecate legacy ports/paths to force migration.

Operational considerations and current pitfalls

  • Clock skew: accurate time across CA, IdP, hosts, and clients is essential. Use NTP/PTP with monitoring and alerts.
  • Protect signing keys: HSMs and MPC provide layered protection—use attestation, audited access, and ensure the signing service is the only path to the key.
  • Usability: provide transparent credential acquisition through CLI agents or background daemons. Friction kills adoption.
  • Device posture: get pragmatic about signal freshness. If posture data is slow, use adaptive policies that allow lower friction while tracking increased monitoring.
  • Supply chain & backups: backup CA configuration but never export private keys unless under strict controls. Test disaster recovery for CA signing capability regularly.

Testing and validation

Validate these scenarios end‑to‑end:

  • Happy path: correct token exchange => PDP allow => signed cert => session established and logged.
  • Expired/stale token: CA rejects and surfaces clear error for the client to refresh tokens.
  • Policy denial: PDP denies and logs reason and policy_version; client shows actionable guidance for remediation.
  • Mid‑session expiry: define behavior—allow continued session with additional monitoring, or enforce immediate session termination depending on risk appetite. Test both with red‑team scenarios.

Real‑world examples & integrations (2026)

Example 1 — Global infra team: a platform team runs a self‑hosted CA (step‑ca) with keys stored in an HSM and MPC backup. Engineers authenticate with OIDC (FIDO2 required), exchange tokens for a CA audience token, then request a 10‑minute OpenSSH cert through a CLI agent. The bastion validates certs, records sessions to object storage, and correlation IDs link issuance events to session logs in the SIEM.

Example 2 — Windows‑heavy shop: IT uses a session broker that integrates with Azure AD device posture and issues ephemeral Windows accounts via Active Directory APIs. Broker enforces owner approvals for contractor access and logs every provisioning/deprovisioning event to a tamper‑resistant store.

Pro tips

  • Use token exchange so the CA only ever sees audience‑restricted tokens; it reduces blast radius if a CA instance is compromised.
  • Embed policy_version in cert key IDs to make retroactive analysis simpler when tying sessions back to rules in effect.
  • Automate key rotation and practice CA disaster recovery annually in controlled drills.
  • Invest in UX: a one‑command flow to obtain and use certs increases adoption and reduces shadow credentials.
  • Consider MPC for signing keys if you need higher assurance without single HSM dependency.

Common mistakes to avoid

  • Keeping TTLs too long for interactive sessions. Minutes not hours for admin access.
  • Exposing the CA signing key or providing direct admin console access to it without gating via the signing service and PDP.
  • Relying solely on token lifetimes without token exchange or audience restrictions—this increases replay risk.
  • Poor telemetry correlation—without serials/policy_version in logs you lose forensic value.
  • Not testing emergency revoke flows or relying on a single operator for break‑glass approvals.

FAQ

Do I need to replace all long‑lived keys immediately?

No. Run a staged migration: inventory keys, pilot a small cohort with dual acceptance, automate removal of legacy keys after validation, and enforce deprecation via bastion/network rules. Immediate replacement can break critical workflows; plan rollouts with fallbacks.

How short should certificate TTLs be in 2026?

Default interactive admin TTLs of 5–15 minutes are best practice. For scheduled maintenance, allow 15–60 minutes with explicit approvals and extra monitoring. Automation tokens may be longer but require rotation automation and scoped permissions.

What is the role of token exchange in this model?

Token exchange (RFC 8693) lets a client swap an IdP token for a narrowly scoped token whose audience is the signing CA. This prevents broad tokens from being reused and reduces the impact if the signing service or client is compromised. Use token exchange wherever your IdP and CA support it.

Can I revoke a certificate mid‑session?

OpenSSH certificates themselves are time‑bound and do not support traditional CRLs. Use a real‑time denylist consulted by bastions/brokers for urgent revocations, and design your session brokers to terminate sessions on denylist hits. Keep denylist propagation latency low.

How should I protect the CA signing key?

Use an HSM or cloud KMS with strict RBAC and audit logging. For higher assurance, adopt MPC/threshold signing so no single host or operator can perform signing alone. Limit signing to a hardened service that validates tokens and consults a PDP; never expose raw keys to operators.

Checklist to go live

  • Document policies, policy versions, and runbooks for emergency revocation and break‑glass.
  • Deploy CA with HSM/MPC protection; automate backups of config (not private keys).
  • Integrate CA with IdP (token exchange) and PDP; test end‑to‑end flows.
  • Deploy bastion/session broker and configure host trust for CA keys. Implement real‑time denylist checks.
  • Implement telemetry and ensure issuance and session logs are correlated in SIEM with policy_version and serial IDs.
  • Train operators, run red‑team and disaster‑recovery drills annually.

Bottom line: JIT access with OIDC and short‑lived certificates remains one of the highest‑value controls for reducing credential exposure and improving observability. In 2026 the model is stronger: token exchange, device‑bound claims, MPC/HSM signing and richer cloud broker integrations make it both more secure and more practical. Build with short TTLs, solid PDP rules, real‑time denylists, and ergonomic tooling—then measure with correlated telemetry to ensure you’ve turned policy into real protection.