A session can't ride on the trust granted at the moment of login
Most gateways verify a user once at login and then assume the session can be trusted until it expires. That assumption is comfortable — and expensive when it fails.
Cookies get stolen and replayed from another country. Browser sessions get hijacked while users are logged in. A single privileged account gets shared by three administrators. A user who started a session on a trusted device walks away and leaves it open on a coffee-shop laptop. None of these moments triggers a fresh login, so none of them is caught by a login-time-only trust model.
The other extreme — short, frequent re-authentication — punishes legitimate users without actually solving the problem, because the time between two challenges is still a window where anything can happen.
Trust earned at login should be continuously re-evaluated as the session progresses — quietly when everything looks normal, decisively the moment it doesn't.
How we approach it
Sessions are bound, watched, limited, and ended through one engine.
Every session has a fingerprint that has to keep matching
At login, the session is bound to the user's IP, user agent, and device fingerprint. Every subsequent request is checked against those bindings. A mismatch is not silently ignored — it triggers a binding-anomaly flow that can re-authenticate, restrict, or terminate the session based on policy.
Re-sync forces a fresh evaluation when something changes
When access policy changes, an attribute is updated, or risk increases mid-session, AAM can force a session re-sync — refreshing the trust context, re-evaluating the conditional access policy, and applying the new rules without making the user start over from the login page.
Concurrent sessions are bounded, not unlimited
A single user cannot have an unlimited number of active sessions. Limits are configurable per user group and per service, so a privileged account cannot quietly be shared by three operators and a contractor laptop cannot fan out into a dozen parallel logins.
Sign-out closes every door, not just one tab
A logout from one application clears the session at the gateway and propagates through every connected service. Stolen tokens become useless, partial sign-outs do not leave background tabs authenticated, and end-of-day sign-out actually ends the day.
Capabilities
The session controls that turn one-time login into continuous trust.
Session binding — IP, user agent, and device fingerprint must keep matching
Every authenticated session is bound to the original IP, the user agent, and a device fingerprint computed at login. A mismatch on any of these signals routes the session through a binding-anomaly flow: re-authenticate, restrict to safe resources, terminate, or log and alert — driven by the conditional access policy for that service.
Forced session re-sync — refresh trust without restarting the user
When the policy that authorized a session changes, when an attribute is updated, or when an external signal demands it, AAM can force a session re-sync. The trust context is rebuilt, the conditional access policy is re-evaluated, and the session continues — without forcing the user to repeat login or lose their work in progress.
Idle and absolute session timeouts
Sessions expire on two clocks: an idle timeout that runs whenever the user is inactive, and an absolute timeout that runs regardless of activity. Both are configurable per service group, so a low-risk intranet app can stay open all day while a privileged admin session expires after a short window of inactivity.
Concurrent session limits per user and per service
Administrators set the maximum number of active sessions per user, per group, or per service. When the limit is reached, a new login can either be refused, replace the oldest session, or require explicit confirmation — preventing silent account sharing and surfacing unusual login bursts immediately.
Comprehensive single sign-out across connected services
Logging out from one application triggers a clean session termination at the gateway, which then propagates through every connected service. There is no orphaned session left active in another tab, no token still valid in a forgotten browser, and no partial sign-out that the user thought was complete.
Session-lost recovery without dropping the work in progress
If a session is temporarily lost — a brief storage hiccup, a forced re-sync, a network outage — the user lands on a recovery page that re-authenticates them and restores their context. The flow is deliberate and audited, not a silent re-login, so a recovery attempt by an attacker would never blend into normal traffic.
Operational depth
The plumbing that makes continuous evaluation reliable, fast, and auditable.
Stateless gateway pods coordinated through Redis
Session state lives in Redis so any gateway pod can pick up any session at any step. Binding checks, re-sync triggers, and concurrent-session counts stay consistent across horizontally-scaled deployments without coordination overhead between pods.
Per-event audit trail
Every session event — bind, mismatch detected, re-sync forced, timeout fired, concurrent limit hit, sign-out — writes a structured audit entry with timestamp, source IP, user agent, and outcome. Sessions can be reconstructed in one timeline from the audit log, and the stream forwards into the platform's SIEM streaming target.
Mid-session step-up MFA orchestration
When a session needs to step up — risk rose, the user reached a higher-sensitivity resource, the policy demands it — the trust evaluator hands off to the MFA action inside the conditional access policy. The user only handles the additional factor; the session itself continues without a fresh login.
Privileged-resource read-only fallback
Instead of dropping a session outright when trust degrades, policy can downgrade it to read-only — letting the user continue viewing what they were doing while preventing any destructive operation. The user sees a clear advisory; the security team sees the decision in the audit stream.
Where teams use it
Stolen session cookie
An attacker who exfiltrates a session cookie and replays it from another network and browser is caught by binding mismatch the moment the first request hits the gateway — without waiting for the user's next login.
Mid-session geographic or device shift
A privileged operator whose source IP changes country mid-session is stepped up to MFA before the next sensitive action; an endpoint that drops out of managed posture has its session downgraded to read-only until the device is back in compliance.
Silent account sharing
A single privileged account that three operators are quietly sharing is surfaced by the concurrent-session limit and the audit timeline — visible from one query without anyone having to admit they were sharing the credentials.
Compliance evidence per session
PCI-DSS, HIPAA, and ISO 27001 audits ask for evidence that privileged sessions are bounded, monitored, and cleanly terminated. Per-event audit gives one timeline per session that the auditor can replay without manual reconstruction.
Common questions
Which signals are matched against the session binding?
How many concurrent sessions can one user have at the same time?
What happens if trust drops mid-session?
Does logout end one tab or every connected session?
Keep trust under evaluation, not under assumption
One engine for binding, lifecycle, concurrent limits, and sign-out — with every session event audited. We'll walk through a live deployment on your applications.