Contact Sales
Rubrik Insights

PACE planning for identity: A Zero Trust Framework for DDIL resilience

Zero Trust assumes continuous connectivity and an always-on IdP, but DDIL environments break that assumption. The PACE military acronym (Primary, Alternate, Contingency, Emergency) extends plans for digital and radio communication platforms to identity infrastructure.

Every military operation has a PACE plan—Primary, Alternate, Contingency, Emergency. It’s how you ensure communications continue when conditions degrade. When Primary fails, you fall back to Alternate. When Alternate fails, Contingency. When everything fails, Emergency.

Here is an example a PACE plan for echeloned sustainment using field, combat, and company trains.
 

Pace Plan Graph


Source: TC 6-02.1, The United States Army Signal Corps 2019 Training Strategy Example unit PACE by phase of an operation

We traditionally only implement PACE plans for digital and radio communication platforms, but identity infrastructure needs the same resilience. Zero Trust mandates continuous authentication. But what happens when your cloud IdP is unreachable? When the network degrades? When you’re operating at the tactical edge with zero connectivity?
 

Pace Plan Graph 2


This framework applies PACE planning to identity, mapping each tier to specific products and capabilities that maintain Zero Trust authentication regardless of connectivity conditions.

The Identity Resilience challenge

The DoD FY27 Zero Trust mandate requires continuous authentication, phishing-resistant MFA, and unified SSO. These requirements assume your identity provider is always reachable.

That assumption fails in DDIL environments:

  • Disconnected: No network connectivity to cloud services
  • Denied: Adversary jamming or intentional air-gap
  • Intermittent: Sporadic connectivity that can’t support continuous verification
  • Limited: Bandwidth too constrained for real-time authentication

Organizations operating in these conditions face a choice: abandon Zero Trust principles when connectivity degrades, or build identity infrastructure that maintains security across all conditions.

PACE planning provides the framework for the second option.

Primary tier: Zero Trust ICAM foundations

Primary is your first choice—the optimal path when conditions are favorable. For identity, that’s your enterprise cloud IdP: Microsoft Entra ID, Okta, Ping Identity, or whichever provider serves as your authoritative identity source.

The enterprise identity gap

DISA is federating ICAM instances across DoD, creating a single identity provider point for millions of users. The intent is clear: unified identity for the enterprise.

The reality is messier. Legacy applications speak LDAP when your IdP speaks OIDC. Mission-critical systems predate modern authentication protocols. Custom access policies are hardwired into application code. Rewriting every app isn’t feasible.

So organizations accept risk. Non-standard apps remain outside the identity fabric. The Primary tier has gaps.

Identity orchestration

Identity orchestration inserts an abstraction layer between applications and identity providers. It translates protocols, maps schemas, and enforces policies—so any app can connect to any IdP without code changes.

Primary tier capabilities:

  • Legacy apps get modern authentication: Extend Entra ID, Okta, or Ping to applications that only understand LDAP or legacy SAML
  • No vendor lock-in: Migrate between IdPs on your terms without rewriting applications
  • Preserve custom policies: Keep access rules while modernizing infrastructure
  • Accelerate authority to operate: Modernize apps without refactoring that triggers full security reviews

NIST 800-53 IA controls

Your Primary tier must satisfy Identification and Authentication (IA) controls:

  • IA-2: Uniquely identify and authenticate users
  • IA-2(1): MFA for privileged accounts
  • IA-2(2): MFA for all network access
  • IA-8: Authenticate external users

Identity orchestration enables these controls across your entire application portfolio—not just apps that natively support modern protocols.

Alternate tier: Multi-IdP resilience

The Alternate tier is your backup when Primary fails. For identity, that means having a secondary IdP ready to take over seamlessly.

The federal identity landscape

Federal and DoD environments navigate multiple identity architectures:

  • FICAM: The government’s standardized approach to identity under GSA
  • SE-ICAM: Department of State’s implementation for diplomatic operations
  • DISA ICAM Federation: Unifying identity across DoD with the Master User Record (MUR)
  • T-ICAM: Army’s effort to extend enterprise identity to the tactical edge

Each represents different IdPs, policies, and schemas. They need to work together.

The Multi-IdP challenge

When Primary fails, Alternate must take over without:

  • Losing active sessions
  • Forcing operators to repeatedly sign in as connectivity flickers—pulling focus from the mission to fight their login screen
  • Breaking access policies
  • Creating audit gaps

Different IdPs use different schemas and claim formats. Failover becomes a translation problem.

Schema abstraction

Identity Continuity includes a Schema Abstraction Layer that maps schemas across incompatible IdPs:

  1. Orchestration layer detects Primary IdP degradation
  2. Failover triggers based on configurable health checks
  3. Schema Abstraction Layer translates claims to Alternate IdP’s format
  4. Users continue working without interruption

This works for cloud-to-cloud failover (Entra ID to Okta, Okta to Ping) and sets the foundation for Contingency tier failover to on-premises systems.

Ready to build identity resilience into your infrastructure? Talk to us about your identity plan.

Contingency tier: Identity continuity

The Contingency tier is where PACE planning gets serious. Primary failed. Alternate is unreachable. You’re operating in degraded conditions—connectivity exists, but it’s unreliable, high-latency, or intermittent.

This is where most Zero Trust architectures break.

The degraded network problem

Zero Trust assumes continuous verification. That model depends on reaching your IdP. In degraded conditions:

  • Authentication requests time out
  • Session validations fail
  • Policy evaluations stall
  • Users get locked out of mission-critical systems

The natural response is to lower security—extend session timeouts, cache credentials longer, skip re-authentication. Every one of those choices creates attack surface.

How failover works

  • Normal operation: Users authenticate against enterprise IdP
  • Degradation detected: Health checks identify latency or availability issues
  • Failover triggered: Authentication routes to local Keycloak
  • Local operation: Keycloak handles all authentication with consistent policies
  • Connectivity restored: Failback occurs; edge audit logs synchronize

What gets preserved

  • Active sessions: Users don’t get logged out during failover
  • Access policies: Rules apply regardless of which IdP is active
  • Audit trail: Every decision is logged and reconciled
  • Strong authentication: CAC/PKI, FIDO2, and phishing-resistant MFA continue working

NIST 800-53 CP-7 alignment

CP-7 (Alternate Processing Site) requires “security measures equivalent to those of the primary site.” Identity Continuity satisfies this for identity services with equivalent authentication, consistent policies, and compliant audit logging.

Emergency tier: Air-gapped identity

The Emergency tier is your last resort. Primary, Alternate, and Contingency have all failed or been intentionally severed. You’re operating in true DDIL with zero ability to reach cloud services.

True DDIL scenarios

  • Contested electromagnetic spectrum: Adversary jamming prevents connectivity
  • Intentional air-gap: Operational security requires disconnection
  • Expeditionary deployment: Beyond reliable communications infrastructure
  • Covert operations: Any external connection would compromise the mission

Identity infrastructure must operate with zero runtime dependency on external services.

Identity hub: Pre-synchronized edge identity

Ideally, an identity hub would provide:

Capabilities: FIPS 140-3 | Sovereign Cloud | IL5-IL7 | Air-Gap

Pre-deployment sync: Before the link is severed, Identity Hub synchronizes user identities from enterprise IdP to local Keycloak at the edge.

Local authentication: When disconnected, Keycloak serves as the authoritative identity source with CAC/PKI, FIDO2, and certificate-based authentication.

Zero cloud dependency: All authentication and authorization decisions are made locally.

Audit capture: Every decision is logged locally and reconciled when connectivity returns.

Compliance at the edge

  • FIPS 140-3: Validated cryptographic modules for government environments
  • Sovereign cloud ready: GCC High endpoint support
  • IL5-IL7 architectures: Complete isolation from commercial cloud

AI agents at the edge

Ideally, identity orchestration that secures humans and services should extend to AI agents at the tactical edge through an AI Identity Gateway:

  • On-premises deployment: No cloud dependency — agent identity runs at the edge
  • Scoped, short-lived credentials: Token exchange with per-tool TTLs ensures agents get only the access they need, only for as long as they need it
  • Runtime policy enforcement: OPA-based policies translate from enterprise to edge
  • Delegation chain auditing: Full traceability from human to agent to tool
  • Human-in-the-loop: Approval workflows for sensitive agent operations

Reconciliation

When connectivity returns:

  • Staging area: Edge changes validate before touching authoritative records
  • Audit reconciliation: Local logs merge with enterprise systems
  • Identity updates: Users modified at the edge synchronize back with conflict flagging

PACE tier overview
 

Tier Condition Capability
Primary Full cloud connectivity Enterprise IdP integration, protocol translation
Alternate Primary IdP unavailable Multi-IdP failover, schema abstraction
Contingency Degraded / intermittent Local Keycloak failover, session preservation
Emergency Denied / air-gapped Pre-synchronized edge identity, zero cloud dependency

Building your PACE identity plan

In an ideal world, here’s how to get started building a PACE identity plan.

Step 1: Establish primary

  • Inventory your identity landscape and IdPs
  • Deploy Identity orchestration between apps and IdPs
  • Connect non-standard apps without code changes
  • Establish baseline authentication and access policies

Step 2: Configure alternate

  • Identify backup IdP (cloud-to-cloud failover)
  • Configure health monitoring and failover thresholds
  • Test failover with outage simulations
  • Document for NIST 800-53 CP compliance

Step 3: Deploy contingency

  • Deploy Keycloak to edge locations
  • Configure phishing-resistant authentication flows (CAC/PKI, FIDO2)
  • Set failover thresholds for degraded conditions
  • Test session preservation and policy enforcement
  • Document reconciliation procedures

Step 4: Prepare emergency

  • Identify air-gapped deployment locations
  • Deploy Identity Hub and edge infrastructure
  • Configure pre-deployment sync scopes
  • Establish reconciliation and staging procedures
  • Train operators for disconnected operations

 

Bottom line

PACE planning for identity isn’t optional for defense operations. It’s not a nice-to-have for organizations in contested environments. It’s a requirement for maintaining Zero Trust when the conditions Zero Trust assumes—continuous connectivity—don’t exist.

  • Primary: Identity orchestration connects any app to any IdP
  • Alternate: Schema Abstraction enables seamless multi-IdP failover
  • Contingency: Identity Continuity maintains authentication in degraded conditions
  • Emergency: Identity Hub delivers air-gapped identity at the tactical edge

Build identity resilience before you need it. The worst time to plan for IdP availability is when it’s already down.

Strata Identity is now a Rubrik Company. Learn how Rubrik's Identity Resilience solutions help you erase attacker footholds and recover IdPs at the speed of AI.