Issue

When an operator’s maximum concurrent session limit is set to 1, signing in from another browser session on a different node does not invalidate the existing browser session. Both sessions remain active and functional, exceeding the configured concurrent session limit.

Symptoms and Impact

• The same operator can use two browser sessions on different nodes despite a maximum concurrent session limit of 1.
• The original session remains usable after the second sign-in.
• The configured restriction on simultaneous operator sessions is not enforced across nodes.

Use case before the resolution

Scenario: An operator is configured to allow only one concurrent session.

1. The operator signs in on Node A, creating the first browser session.
2. The operator signs in on Node B using the same operator ID.
3. The operator returns to the first session on Node A and performs an action.

Expected result: The second sign-in supersedes the first session. Only the new session should remain authenticated and usable.

Actual result: The first session remains authenticated and functional. The second session is also usable, allowing the operator to work in both sessions simultaneously.

Steps to reproduce

1. Configure the operator’s maximum concurrent session limit as 1.
2. Sign in with the operator ID on Node A.
3. Sign in with the same operator ID in another browser session on Node B.
4. Return to the session on Node A and perform an action. Observe that both sessions remain functional.

Root Cause

The existing concurrent session enforcement flow did not reliably invalidate a superseded browser requestor hosted on another node.

Cross-node enforcement requires the invalidation operation to execute on the node that owns the original requestor. Without an effective distributed invalidation mechanism, the original requestor can remain authenticated after a new session is established.

Solution

Update to one of the following Pega Platform versions:

• Pega Platform 25.1.4
• Pega Platform 26.1.1
• Pega Platform 27

The resolution adds a dedicated concurrent-session invalidation job and integrates it with the requestor management APIs.

When a new sign-in supersedes an existing browser session:

• The system identifies the requestor associated with the superseded session.
• If the requestor is local, the invalidation operation is executed locally.
• If the requestor is hosted on another node, an invalidation job is dispatched asynchronously to that node.
• If the target node is unknown or unavailable, the remote dispatch mechanism falls back to a cluster-wide search.
• The job unauthenticates and invalidates the superseded browser requestor.
• Logging and error handling support diagnosis of distributed invalidation failures.

After invalidation completes, the original session can no longer process authenticated requests, and the operator continues working in the new session. Remote invalidation is asynchronous.

Use case after the resolution 

Scenario: The same operator, configured to allow one concurrent session, signs in on Node A and then Node B. 

1. The operator signs in on Node A, creating the first browser session. 
2. The operator signs in on Node B using the same operator ID. 
3. The system initiates invalidation of the superseded requestor on Node A. 
4. The invalidation job executes on the node hosting the original requestor and unauthenticates it. 
5. After invalidation completes, the original session can no longer process authenticated requests. 
6. The operator continues working in the new session on Node B. 

Result: The superseded browser session is no longer authenticated, and the new session remains usable. 

Timing note: Remote invalidation is asynchronous.

Behavior comparison