If an attacker manages to steal a user's session cookie — by intercepting traffic, exploiting an XSS bug, or pinching it off an unattended device — they can typically use it from anywhere, on any browser. ActiveManage offers two additional checks that make stolen-cookie attacks much harder, at the cost of some inconvenience for legitimate users whose connection or browser legitimately changes mid-session.
Both settings sit under Site Settings → Session and both only take effect when Always Check Session is also on — without that, the platform doesn't look up the session per request and so can't run the comparison.
Verify User's IP Address
When this is on, the platform stamps the user's IP into their session at login. Every subsequent request compares the incoming IP to the stamped one. If they don't match — typically because the user moved between networks — the session is invalidated and the user is forced to log back in.
For desktop users sitting at a single workstation all day, this is invisible. For mobile users it's a constant nuisance: walking from the office Wi-Fi to the lift's 4G connection counts as an IP change, as does the morning commute moving between cell towers. Most modern apps avoid IP-pinning for this reason.
There's a third group it's actively wrong for: users behind carrier-grade NATs (often the case in mobile networks) where the apparent IP can rotate every few minutes without the user moving at all. In those environments, IP-pinning effectively logs the user out constantly.
The platform's own documentation captures the right summary: this option isn't recommended for mobile users that switch between mobile and Wi-Fi connections. Enable it for hardened admin-only environments; leave it off for anything customer-facing.
Verify User's Browser User Agent
This compares the visitor's browser User-Agent header against the User-Agent stamped at login time. A mismatch — almost always because the browser auto-updated mid-session — logs the user out.
It's less intrusive than IP-pinning because most browsers' User-Agent strings stay stable for hours or days at a time. It catches the easiest form of cookie theft, where an attacker grabs the cookie and pastes it into a different browser entirely.
The catch: anti-tracking browsers like Brave and Safari sometimes randomise User-Agent components for privacy. And every Chrome auto-update flips the version number, which counts as a change. Test in your user population before turning it on.
Combined effect
With both on, an attacker who steals a session cookie would need to spoof both the original IP and the original User-Agent to use it. That's hard. The legitimate-user cost is real though — IP changes from network roaming, plus User-Agent changes from browser updates, mean users see unexpected re-login prompts every few days.
Recommended configurations
Three sensible profiles, depending on your threat model:
- Maximum security (internal admin tools): Always Check Session + Verify IP + Verify User Agent + short Idle Time (15 min). Locks down hard at the cost of UX.
- Balanced (typical business apps): Always Check Session + Verify User Agent only. Catches obvious cookie theft without disrupting mobile users.
- Convenience-first (consumer apps, marketing portals): Always Check Session off; rely on session expiry and HTTPS for cookie protection.
Warning: If you're considering enabling IP verification for an app with any mobile usage, run it past your support team first. They'll be the ones answering "why did I get logged out again?" tickets.