Identity in DDIL and Disconnected Environments Guide

Modern identity assumes a reachable identity provider, but ships, deployed units, remote industrial sites, field teams and stores regularly lose that connection, and when they do, either nobody can sign in or the controls quietly stop working. DDIL stands for denied, disrupted, intermittent and limited bandwidth: environments where connectivity to central services cannot be relied on. The US Department of Defense's Digital Modernization Strategy, quoted in its Zero Trust Strategy, describes deployed tactical components designed to work with core infrastructure and also to operate autonomously should that connectivity be lost or denied. This guide explains which identity functions depend on the network, the patterns for authenticating people, devices and workloads offline, how to handle revocation and policy when you cannot reach the source of truth, how to reconnect safely, and how to test it. It is for identity architects, OT and edge engineers, and resilience teams in defence, maritime, energy, utilities, retail and any organisation with sites that can be cut off.

Key takeaways

Decide in advance what works offline. For each site and function, decide which sign-ins, authorisations and machine-to-machine calls must continue without the central identity provider, and design for those, rather than discovering the answer during an outage.
Offline means cached, and cached means stale. Every offline pattern relies on something issued earlier: a cached password verifier, a ticket, a certificate, a token or a policy. Bound how long each may be used (NIST SP 800-53 IA-5(13) Expiration of Cached Authenticators).
Revocation is the hard part. A disabled account or revoked certificate may keep working until the cached artefact expires. Short lifetimes and explicit revocation on reconnection are the controls.
Machines need offline identity too. Workloads, controllers and sensors at the edge need certificates or keys with lifetimes long enough to survive a disconnection but short enough to limit theft.
Reconnection is a security event. Reconcile accounts, logs and revocations when the link returns, and treat the period offline as reduced assurance in investigations.

Which identity functions depend on the network

Map every step of authentication and authorisation for the site to the service it calls. Anything that calls a central or cloud service fails or degrades in DDIL.

Function	Typical online dependency	What happens when disconnected
Interactive sign-in to a domain-joined device	Domain controller	Windows uses cached logon verifiers if any exist (default 10 cached logons); otherwise sign-in fails
Cloud identity provider sign-in (SAML, OIDC)	Internet access to the IdP	New sign-ins fail; existing sessions continue until they expire; some providers offer limited backup authentication
MFA (push, SMS, FIDO2 with cloud verification)	IdP and often a mobile network	Push and SMS fail; locally verifiable factors (smart cards, FIDO2 to a local verifier, TOTP checked locally) can still work
Certificate validation	CRL distribution points and OCSP responders	Validation fails or falls back to cached CRLs; Microsoft notes that disconnected Azure Stack Hub deployments fail with public CA certificates because CRL and OCSP need internet access
Kerberos service access	KDC on a domain controller	Existing tickets work until expiry (user ticket default 10 hours); new tickets need a reachable KDC
Authorisation decisions	Central policy decision point, directory group lookups	Decisions fail, or use cached policy and group membership from the last sync
Workload identity (certificates, tokens)	Central CA, SPIFFE server, cloud token service	Workloads keep their current credentials until expiry, then fail mutual TLS or API calls
Privileged access (PAM, vault check-out)	Central vault	Administrators cannot retrieve credentials unless a local break-glass path exists
Logging and detection	Central SIEM	Events queue locally or are lost; detection is delayed

Patterns for authenticating offline

No single pattern fits every site. Most designs combine a local authority for the site with cached credentials for individual devices.

Pattern	How it works	Good for	Risks and limits
Cached domain credentials	Windows caches logon verifiers; set by "Interactive logon: Number of previous logons to cache (in case domain controller is not available)", range 0 to 50	Laptops and mobile users who travel	Microsoft warns that attackers with file system access can brute-force cached verifiers (ATT&CK T1003.005 Cached Domain Credentials); disabled accounts may still sign in offline
Local directory replica or site IdP	A read-only domain controller, directory replica or local identity provider at the site, synchronised when connected	Ships, bases, plants and large sites	Physical security of the site server; replication lag; must be patched and monitored like any domain controller
Smart cards and PIV with local validation	Certificate-based logon validated against a locally available CA chain and cached revocation data	Defence and government users with PIV or CAC	Revocation data ages; card loss handling depends on how fresh the local CRL is. See the Smart Card and PIV/CAC Authentication Guide
Cloud backup authentication	The provider keeps a secondary service that reauthenticates previously signed-in users; Microsoft Entra's backup authentication system covers users who accessed an app in the last three days from the same device	Cloud IdP outages, where the site still has internet	Does not help with no internet; no interactive sign-ins; no fresh revocation checks
Locally verifiable MFA	Factors that a local verifier can check without the cloud, such as smart cards, hardware keys enrolled with a local verifier, or TOTP seeds held by the local system	Keeping MFA during disconnection	Seeds and verifiers on the site become sensitive; enrolment must happen while connected
Break-glass local accounts	Local administrator or emergency accounts with passwords managed and rotated by Windows LAPS and escrowed to AD or Entra ID	Last-resort device recovery	Must be retrieved before disconnection or held in a sealed local process; see the Break-Glass Account Guide

Choosing a pattern

Short, rare outages at sites with internet: cloud backup authentication, sensible session lifetimes and a small cached logon count (Microsoft suggests 2 for end-user computers where caching must be kept) are usually enough.
Long or frequent disconnection with many users: run a local authority (directory replica or site IdP) and local certificate validation. Treat the site server as tier 0.
Single devices in the field: cached credentials plus a hardware-backed factor, with strict expiry, encrypted disks and remote wipe when connectivity returns.
Small organisations: start by listing which systems must work offline and making sure there is at least one documented, tested local sign-in path for each, with its credentials escrowed.

Expiry, revocation and the stale-trust problem

Offline authentication trades freshness for availability. Microsoft's Kerberos guidance shows the trade-off clearly: if the maximum user ticket lifetime is too long, users whose accounts were disabled might keep access with tickets issued before they were disabled; if too short, the KDC is loaded more heavily. Microsoft's Entra documentation states that its backup authentication system cannot perform fresh revocation checks and relies on the CRL state from when the session was last backed up, and advises explicitly revoking sessions rather than waiting for the CRL.

Cached artefact	Lever	Guidance
Cached logon verifiers	Cached logon count; account disablement on reconnection	Keep the count as low as operations allow; force sign-in online at least periodically
Kerberos tickets	Maximum lifetime for user ticket (default 10 hours; Microsoft suggests 4 to 10)	Use the low end where sites are mostly connected
Certificates (people and machines)	Validity period, CRL publication interval and overlap	Publish CRLs with a validity window longer than the expected disconnection; distribute them to site caches before planned outages
Cloud sessions and refresh tokens	Session lifetime, sign-in frequency, revocation	Revoke explicitly on reconnection for anyone who left or lost a device while offline
Workload credentials	SVID or certificate lifetime, rotation point	Set lifetimes to cover the longest expected outage plus margin
Cached policy and group membership	Policy sync interval and maximum age	Define a maximum age after which high-risk actions are denied

NIST SP 800-53 gives you the control language for this: IA-5(13) requires prohibiting the use of cached authenticators after an organisation-defined period, and CP-13 requires alternative security mechanisms when the primary means of implementing a security function is unavailable or compromised. Writing the period down per site and per artefact type is the practical step most designs skip.

Authorisation and policy when the decision point is unreachable

Zero trust architectures place a policy decision point centrally and enforcement points near resources. In DDIL, either the decision point must be replicated to the site or enforcement points must decide from cached policy. Decide per action whether it fails open or closed.

Action type	Suggested offline behaviour	Reason
Safety-critical operation (ship systems, plant control, clinical devices)	Continue with cached authorisation; log locally	Losing operation is the greater harm
Routine business access to local data	Continue with cached policy up to a maximum age	Keeps work going; bounded risk
Privileged change (new accounts, permission grants, security settings)	Require a local privileged path with two-person approval, or defer until reconnection	High impact and hard to reconcile
Access to central or cross-site data	Not possible while disconnected; queue requests	The data is not reachable anyway
Onboarding new users or devices	Defer, or use a pre-approved emergency enrolment process with later review	Identity proofing and enrolment need the authority

Cloud providers make similar choices for you. Microsoft documents that during an outage Conditional Access uses a prior evaluation by default (for example, the role a user had at the latest authentication), that admins can disable resilience defaults for strict evaluation at the cost of excluding those users from backup authentication, and that sign-in frequency and authentication strength controls reduce resilience. Understand your provider's defaults before an outage, because they must be set beforehand.

Where identity fits: workloads and devices at the edge

In DDIL environments machines often outnumber people: sensors, controllers, gateways, vehicles and the services running on them authenticate to each other with certificates and keys. These non-human identities fail silently when their credentials expire during a disconnection.

Size lifetimes to the outage: SPIRE, the SPIFFE reference implementation, issues X.509 SVIDs with a default lifetime of one hour and rotates them at half their lifetime by default. Its availability_target setting (at least 24 hours) makes the agent rotate earlier so that workload X.509 SVIDs remain valid through a defined period of server or agent downtime. Plan the equivalent for any workload PKI.
Keep a local issuer where outages are long: an intermediate CA or SPIFFE server at the site, chained to the central root, lets workloads rotate while disconnected. Protect its key in hardware. See the Device and IoT Identity Guide.
Use the right identity type in the cloud: Microsoft notes that managed identities for Azure resources receive increased resilience from its backup authentication system, while service principals that are not managed identities are not protected.
Protect credentials at rest: devices in the field can be captured. Hardware-backed keys, disk encryption and a plan to revoke device identities on loss are essential. See the Edge Computing Security Guide.

Reconnection and reconciliation

Push revocations first: as soon as the link returns, distribute new CRLs, account disablements and session revocations to the site before resuming normal synchronisation.
Synchronise directories and resolve conflicts: decide which side wins for each attribute; changes made locally while disconnected need review.
Ship and review local logs: forward queued authentication and authorisation logs to the SIEM and review offline privileged actions and break-glass use.
Rotate what was exposed: rotate break-glass passwords that were used (Windows LAPS can rotate them automatically), and reissue credentials for any device lost or suspected compromised.
Restore normal assurance: force online sign-in and MFA for users who worked only on cached credentials during the outage.

Testing and planning

Write a PACE plan for identity: primary, alternate, contingency and emergency methods for sign-in, MFA, authorisation and privileged access at each site, with who decides to switch.
Test disconnection on purpose: cut the site's link in a planned exercise and check that users can sign in, workloads keep talking, privileged access works through the local path and logs queue.
Test long outages: run past the shortest credential or CRL lifetime to see what breaks first.
Test reconnection: confirm revocations apply, logs arrive and conflicts are handled.
Keep the plan with the degraded mode plan: see the Degraded-Mode Operations and Manual Workarounds Guide for the business side of operating without systems.

Detection and measurement

Metric	What it shows	Target
Sites with a documented and tested offline sign-in path	Readiness	100% of sites that can be cut off
Longest credential or CRL lifetime shorter than the longest expected outage	Where outages will break authentication	None, or accepted with a workaround
Time from reconnection to revocations applied at the site	Stale-trust window	Minutes
Cached logon count by device group	Offline credential exposure	As low as operations allow; justified per group
Break-glass and offline privileged actions reviewed after each outage	Accountability	100%
Local log loss during outages	Detection coverage	Zero; local buffers sized for the longest outage

For cloud backup authentication, Microsoft notes that backup-issued tokens can be found in Entra sign-in logs by filtering on token issuer type "Microsoft Entra Backup Auth"; track their volume during and after outages.

Common failure patterns

Discovering dependencies during the outage: a site loses its link and nobody can sign in because MFA, the vault or certificate checks were all cloud-dependent.
Unbounded cached credentials: the cached logon count is left at the maximum and devices are never forced back online, so former staff can still sign in to field laptops.
CRLs that expire before the outage ends: certificate validation fails across the site, and someone disables revocation checking to restore service, and never turns it back on.
Workload certificates sized for the data centre: one-hour certificates with no local issuer stop machine-to-machine traffic an hour into the disconnection.
Break-glass that needs the network: the emergency account's password is in a cloud vault that cannot be reached.
No reconciliation: accounts disabled centrally during the outage are never pushed to the site, and local changes are never reviewed.

Framework mapping

Framework	Reference	How it applies
NIST SP 800-53 Rev. 5	IA-5(13) Expiration of Cached Authenticators; CP-13 Alternative Security Mechanisms; CP-2 Contingency Plan; CP-8 Telecommunications Services; IA-11 Re-authentication; AC-12 Session Termination	Bounded caching, alternative mechanisms, contingency planning for links, re-authentication on reconnection
NIST CSF 2.0	PR.IR-03; GV.OC-04	Resilience mechanisms in adverse situations; understanding critical services that must continue
MITRE ATT&CK v20	T1003.005 Cached Domain Credentials; T1078.003 Local Accounts	Theft of cached verifiers from captured devices; abuse of local and break-glass accounts
MITRE D3FEND	D3-CH Credential Hardening	Hardware-backed keys and bounded credential lifetimes for offline use

Practitioner checklist

Map every identity dependency (sign-in, MFA, certificate validation, authorisation, vault, logging) for each site that can be cut off.
Decide per action whether it fails open or closed offline, and document the maximum age of cached policy.
Choose an offline pattern per site: cloud backup authentication, local authority, or cached credentials with hardware factors.
Set and record expiry for every cached artefact (IA-5(13)): cached logons, tickets, CRLs, sessions, workload credentials.
Size workload and device credential lifetimes, and local issuers, to the longest expected disconnection.
Provide a break-glass path that works without the network, with LAPS-managed passwords and post-use rotation.
Buffer authentication logs locally and forward them on reconnection.
On reconnection, push revocations first, then synchronise, review offline privileged actions and force online re-authentication.
Exercise disconnection and long outages at least annually, including reconnection.

Identity in DDIL and Disconnected Environments Guide: Keep Authentication Working When the Network Fails