Does Your Identity Platform Work When the Cloud Doesn’t?

By Shawn Moorhead, Head of U.S. Sales, Lastwall

Consider a hypothetical regional water utility responding to an intrusion on its corporate network. Its incident plan calls for disconnecting the treatment plant's control network from corporate IT.

The plan works. The plant's local applications stay up, and the network inside the plant keeps running. Then the relief operator arrives for the morning shift and tries to sign in.

The request fails. The identity service needed to approve access sits on the corporate side of the separation.

For organizations responsible for defense missions, government operations and critical infrastructure, this is a scenario worth testing. Applications can remain available locally while access depends on a central directory, cloud identity provider or policy service beyond the operational environment.

Recent outages show how those dependencies can interrupt access. They also raise a question every operator should be able to answer: can your organization maintain secure local identity operations when its connection to central services disappears?

An existing session can hide an access problem

On November 18, 2025, Cloudflare reported widespread authentication failures affecting its Access service¹. Existing sessions continued to work, but users attempting to sign in could not reach their applications.

The incident illustrates how dependent application availability can be on authentication services. An application may be running normally, yet remain inaccessible to users who need to establish a new session. Existing users may continue working while others are locked out.

The outage does not establish that a locally operated identity platform would have prevented the disruption. It does, however, raise an important question about how organizations manage their dependencies on external authentication services, particularly when those services become unavailable.

Access can depend on infrastructure outside your environment

During the October 19–20, 2025 AWS outage, some customers were unable to sign in to their accounts, including when accessing services in regions unaffected by the original disruption.²

The incident showed how authentication can depend on shared infrastructure, even across regions. This is particularly important for remote facilities, deployed platforms, and isolated networks where external connectivity may be limited or unavailable.

A locally hosted application does not necessarily provide local independence. Its authentication, access management, or supporting certificate services may still depend on an external connection.

Recovery access can share the same dependency

The same concern extends to recovery. During the AWS outage, its support service successfully switched to another region, but a separate dependency prevented customers from accessing support functions. The failover worked, yet parts of the support service remained unavailable.² 

Cloudflare experienced a similar problem during its June 12, 2025 outage. An emergency function designed to disconnect users from its network became unavailable because it relied on another service affected by the outage. Access to its management dashboard was also disrupted.³

Both incidents show how the tools needed to respond to an outage can depend on the same infrastructure experiencing the disruption. Recovery plans must account for those dependencies, including whether administrators can access management tools and carry out emergency procedures when external services are unavailable.

The DDIL requirement is local operational independence

Denied, degraded, intermittent and limited connectivity, commonly described as DDIL, creates a specific identity requirement: an operational environment may need to authenticate users and enforce access rules while central identity services cannot be reached.

That is the water utility's problem. The operator already on the plant floor may keep working, depending on the application. The relief operator may not be able to sign in. This is the gap local identity operations are designed to address.

The requirement is to keep approved authentication and access decisions available within the operational environment, with defined limits and local administrative authority.

Joint CI Fortify guidance published in July 2026 reinforces the importance of this planning. It calls on critical infrastructure operators to prepare for isolating vital operational technology and supporting systems, and identifies shared identity, certificate and time services among the dependencies that can impede effective isolation.⁴

Where Lastwall fits

Lastwall IDCommand Tactical is designed to maintain local identity operations when enterprise directories or cloud services cannot be reached.

Lastwall IDCommand Tactical is a lightweight, self-hosted identity platform that supports local authentication, credential management, user provisioning and access management when enterprise identity services are unavailable. It also supports synchronization and reconciliation of identity and audit activity when connectivity returns.⁵

For a deployed team or infrastructure operator, the benefit is concrete: losing the central connection does not have to remove the ability to authenticate authorized users or administer access to available local systems.

That capability must be designed into the deployment. Local applications, network connections and supporting services still need to function. A disconnected identity platform cannot restore a failed network or make an unreachable cloud application available.

Security teams need to establish which workflows can operate locally, what they depend on and how long they must remain independent.

Extend your existing identity investment

Supporting disconnected operations does not necessarily require replacing your existing IAM platform. Lastwall IDCommand can integrate with existing directories and identity services, helping organizations extend their identity architecture to environments where central services cannot always be reached.⁵

With IDCommand Tactical deployed locally, authorized users can authenticate to supported local applications during disconnection, while approved administrators retain the ability to manage roles and revoke access. Identity and audit activity synchronize when connectivity returns.⁵

Organizations need to understand which applications are supported, which identity functions remain available locally and how changes are reconciled after reconnection.

Test a complete shift, mission or maintenance window

Tests should reflect the operation that the organization needs to sustain.

In a controlled environment, disconnect the central identity service while keeping the required local applications and network available. Walk through the following scenarios:

• An authorized user establishing a new application session.
• Authentication after a device restart.
• Behavior when sessions, credentials or certificates expire.
• Approved local role changes and access revocation.
• Denial of unauthorized access and preservation of audit records.
• Reconnection and reconciliation of local and central changes.

Run the exercise for a duration that reflects the requirement. A short demonstration may miss dependencies that emerge after several hours or days.

Also examine what the disconnected environment cannot know. A revocation made centrally cannot take effect locally until that information arrives through an approved mechanism. Define acceptable information age, credential validity and local authority before deployment.

Continued access needs explicit security boundaries.

Make local identity continuity part of acceptance

At Lastwall, we believe identity providers (IdPs) must work under degraded and disconnected conditions.

The Cloudflare and AWS incidents show how shared dependencies can prevent access or complicate recovery. DDIL planning takes that lesson into the operational environment: determine which identity functions must remain available locally, then prove they do.

Identity platforms should be evaluated by disconnecting them from central identity services and testing a complete operational workflow. 

Can a new shift sign in? Can an administrator remove access? Can the organization account for the decisions made while disconnected?

Those answers establish whether secure access can continue when the connection cannot.

References

1. Cloudflare. Cloudflare Outage on November 18, 2025. Read the incident report.
2. Amazon Web Services. Summary of the Amazon DynamoDB Service Disruption in the Northern Virginia (US-EAST-1) Region. October 19–20, 2025. Read the post-event summary.
3. Cloudflare. Cloudflare Service Outage June 12, 2025. Read the incident report.
4. Australian Signals Directorate and international partners, including CISA. CI Fortify: Advice for Isolating Vital Systems. July 2026. Read the guidance.
5. Lastwall. IDCommand: Trusted Access in Disconnected Environments. Read the product information.

‍