What breaks when Passbolt sessions stay on a single node in a high-availability setup?

Why single-node session state breaks in a high-availability Passbolt setup

Passbolt can remain reachable while session continuity fails if each node keeps its own local session state. That means authentication succeeds, but the next request may land on a different node that does not recognise the session, so the user appears intermittently logged out or inconsistently authorised. In high availability, availability of the app is not the same as continuity of identity state.

What the user actually experiences

The failure usually shows up as inconsistent behaviour rather than a clean outage. One request works, the next prompts for re-authentication, and actions can appear to succeed on one node but fail on another. That pattern is especially confusing because the platform itself is still serving traffic, so the problem looks like instability rather than a hard service failure.

At the system level, the load balancer is doing its job, but it exposes a split view of the same authenticated user. A session created on node A is invisible on node B unless session data is shared, replicated, or backed by a common store. The issue is therefore not the login step itself, but the persistence of state after login.

Why this matters for clustered authentication flows

Any design that treats session state as local to a node creates a hidden dependency on stickiness. If traffic affinity changes, failover occurs, or the balancer re-routes requests during maintenance, the user’s authenticated context can disappear. That makes the system behave as though the session boundary is part of the node, when it should be part of the shared service.

This is why high-availability design has to include identity continuity, not just process continuity. A cluster can be healthy at the infrastructure layer and still fail at the user layer if one node cannot validate what another node issued. Shared session storage, consistent cache behaviour, or another centralised session mechanism is what prevents that split-brain experience.

Risk and Threat Considerations

Session locality creates an availability and trust risk because users may be bounced between nodes that disagree about whether they are authenticated. In practice, that can lead to repeated logins, interrupted workflows, and mistaken assumptions about whether an action really completed.

Failure mechanism: A session is established on one node, but the next request is routed to another node that lacks the matching session record, so the application cannot reconstruct the authenticated context.

Impact: The service remains online, but user state becomes inconsistent, failover becomes unreliable, and operational confidence in the cluster drops because authentication appears unstable even without an underlying outage.

Practitioner Guidance

What to verify: Confirm that session state survives node changes during normal traffic shifts and deliberate failover tests, not just during happy-path login. If a user can authenticate successfully but loses context after a balancer decision, the HA design is incomplete.

Implementation sequence: First decide where authoritative session state lives, then test whether every node can read the same state consistently under load, restart, and failover conditions. Only after that should you treat the cluster as session-safe.

Common mistake: Relying on sticky sessions as the primary fix without planning for node loss or rebalance events. Affinity can mask the problem until the first failover, which is usually when the weakness matters most.

Practitioner takeaway: In a highly available deployment, the real control objective is not just keeping Passbolt reachable, but keeping the authenticated session coherent across nodes so identity state does not fragment during routing changes.

Related resources from NHI Mgmt Group

• Why do high-activity devices create more fraud risk than single suspicious sessions?
• What breaks when AI security agents depend on a single provider for both capability and availability?
• When does a clustered access backend create more value than a simple single-node setup?
• What breaks when OpenTelemetry Collector high availability is not configured correctly?