Configure Access Risk Detection

JumpCloud’s Access Risk Detection continuously monitors login activity across your organization and identifies logins that look suspicious. To begin assessing your system’s access risk, you must first define the Access Risk Detection configurations.

1. Login to the JumpCloud Admin Portal.

2. Go to Monitoring > Access Risk.
   

Access Risk consists of two tabs:

• Overview: Provides a high-level summary of all risk detections across your org with real-time risk factors and trend data, allowing you to monitor the overall health of your environment at a glance.
• Detections: Lists all identified detections with all important factors such as Severity, Status, Location, time and so on.

Setting Up Access Risk Detection

The first time you open Access Risk, you will view the Overview dashboard. To begin, you need to enable the feature in the Configuration page where you can also configure the settings for Access Risk and select your default landing page.

1. In the Overview page, click Configuration.
2. Enable Access Risk Detection.
   1. In the Configuration page, use the toggle to enable Access Risk Detection. Once enabled, Access Risk begins evaluating all login events in your organization. 
3. (Optional) Select the default landing page. You can customize your Access Risk experience by selecting a default landing page from the dropdown menu.
4. (Optional) Choose the risk factor you want to monitor. Access Risk evaluates nine different signals. Unusual Time factor is set to off by default. You can enable/disable any signal you don't want to track.

5. (Optional) Configure MFA auto-resolution - If MFA is configured in your organization, you can have Access Risk automatically close detections when the user successfully completes an MFA challenge. This reduces the number of detections your admins need to review manually.
   • In the Auto Resolution section, select the Auto-Resolve on MFA Success checkbox. If MFA is not yet configured, click the Configure MFA link to set it up. See Get Started: MFA to learn more.

6. (Optional) In the Notifications section, configure when and how you want to be notified.
   • Click Add Condition.
   • Select one or more Severity levels for the detection.
   • From the Notification Channel dropdown, choose where to send the alerts. You can send notifications via Email, Webhooks, or Slack.

6. Configure Advanced Settings - Use the Advanced Settings section to define specific thresholds for physical travel, trusted networks, and High Volume/Failed login indicators. Jump to Understanding Advanced Settings to know more about each.
   • Under Impossible Travel: Distance Threshold, enter the minimum physical distance (in kilometers) required to trigger a travel velocity alert. The default recommended value is 500 km. Setting lower thresholds may increase false positives for mobile device users.
   • Under Max Speed Threshold, enter the maximum speed threshold (in km/h) required to trigger an impossible travel detection.

1. Under Trusted IPs and Networks field, enter the specific IP addresses belonging to your network that you want to exclude from geo-location alerts. This prevents false alarms from VPNs, NAT gateways, or centralized egress infrastructure.
2. Under Unusual Login Time, enter the Familiar Login Time Window value. This defines how many hours before and after a user's typical login time are considered familiar. The system uses UTC hours to match behavioral profiles. Weekday matching does not use a radius.
   Let’s consider the following examples of a few hour familiarity radius values:
   - 2: Matches up to two hours before and after the known login hour.
   - Higher numbers: Increases tolerance for users with irregular login schedules.
3. Under High Volume/Failed Logins: Thresholds, configure your rolling 24-hour brute-force parameters:
   • High Volume Logins Threshold: Enter the maximum number of allowed successful logins from a single user within 24 hours before a detection triggers.
   • Excessive Failed Logins Threshold: Enter the maximum number of allowed failed login attempts from a single user within 24 hours before a detection triggers.
   • Login Volume Spike Multiplier - It measures current login activity against the user's typical daily average. To trigger this detection, a user's login count must beat their daily average by the multiplier you set here (while also passing your minimum count rules).
4. Under Dormant Account, configure the Dormant Account Threshold field. Enter the minimum days since the last successful login before dormant-account detection triggers.
5. Under Behavioral Detection, configure the Minimum Login History field. Enter the minimum login history samples required before behavioral novelty detections (such as unusual geolocation, user agent, application, login time, and new device login) trigger.

Once the setup is done, you will view your selected landing page first when you login again. After a day or two of live monitoring, the Overview dashboard will begin populating with:

• Total detections count reflecting recent login events
• A login types breakdown showing which login surfaces are contributing to risk
• A geo-location distribution map showing where your users are logging in from

If you see no detections at all after several days, verify that Access Risk Detection is still toggled on in Configuration and that login events are flowing through Directory Insights.

Understanding Advanced Settings

Impossible Travel: Distance Threshold

An Impossible Travel risk factor triggers when a single user account logs in from two separate geographic locations within a timeframe that is physically impossible to achieve by commercial aviation (for example, authenticating from New York and then authenticating from Tokyo just one hour later).

JumpCloud doesn't just look at the distance; it looks at Distance ÷ Time Elapsed. If a user logs in from Location A and then Location B, the system calculates the distance between those two IP addresses and checks how long it took the user to travel that far. If the resulting speed required to make that trip is physically impossible, an alert triggers. 

• If you set this value too low, a user whose mobile phone rapidly hops between a cellular tower in one town and a Wi-Fi network in a neighboring city might trigger a false positive.
• If you set this value too high, you might miss tighter-range local credential compromises.

Trusted IPs and Networks

When users authenticate through corporate VPNs, cloud egress gateways, or shared infrastructure, the source IP doesn't reflect their actual location. This can cause Unusual Geolocation or Impossible Travel detections for legitimate sessions.

Adding an IP to the Trusted IPs list tells JumpCloud to disregard that source when evaluating geolocation-based risk. For example, an employee in Chicago connecting through a VPN gateway in Germany will appear to authenticate from Germany. Adding the German gateway's public IP suppresses the false alert.

What's affected: Only Unusual Geolocation and Impossible Travel are suppressed for trusted sources. All other risk factors continue to evaluate normally. The authentication event is still logged for audit.

Supported Network Formats

The configuration field accepts public IPv4 and IPv6 addresses. To ensure proper parsing, enter your network infrastructure parameters using the following standardized formats:

Trusted ASNs

The Trusted ASNs setting lets Admins specify Autonomous System Numbers (ASNs) for trusted corporate egress networks, such as corporate VPNs, secure web gateways (SWGs), or Zero Trust Network Access (ZTNA) providers. Logins originating from ASNs on the Trusted ASN list are excluded from location-based detections, such as Unusual Geolocation and Impossible Travel.

Alternatively, enable Suppress risk score for trusted ASNs to generate these detections at reduced severity instead of suppressing them entirely.

Example

Many organizations route employee traffic through a secure web gateway (SWG) or corporate VPN. Depending on whether a user is connected to the gateway, the same user may appear to sign in from different cities or countries because the login originates from the gateway's egress location rather than the user's physical location. This can trigger location-based detections such as Impossible Travel even though the login is legitimate.

For example:

• AS62044 (Zscaler) may be added as a Trusted ASN if your organization uses Zscaler as its corporate secure web gateway.
• AS16509 (AWS) should not be added because it represents shared cloud infrastructure used by many organizations.

Consider the following scenario:

1. A user signs in from New York while connected directly to the internet.
2. Later, the same user signs in while connected through Zscaler, and the login appears to originate from London, where the organization's Zscaler egress gateway is located.
3. AS62044 (Zscaler) has been added to the Trusted ASN list.

High Volume/Failed Logins: Thresholds

By configuring the High Volume/Failed Logins: Thresholds, you can catch anomalous bots, credential-stuffing campaigns, and attacks that operate over an extended window.

High Volume Logins Threshold

This tracks an unusual surge of successful authentications tied to a single identity.

• Enter the maximum number of successful logins allowed from a single user within a rolling 24-hour window before triggering a threat detection. This is set to 50 by default.

Under normal business operations, it is rare for a single human user to successfully log in dozens of times within 24 hours. A surge crossing this boundary frequently indicates machine-driven programmatic access, such as compromised credentials being used by an attacker to rapidly scrape data.

Excessive Failed Logins Threshold

This tracks low-and-slow authentication failures targeting an individual account name.

• Enter the maximum number of failed login attempts allowed from a single user within a rolling 24-hour window before a risk detection is generated. This is set to 20 by default.

This setting is specifically engineered to flag "slow" password-guessing or credential-stuffing patterns that remain just below your strict lockout policies.

For example, if your company’s password policy locks an account after 5 failed attempts in 5 minutes, an attacker might script an attack to attempt only 3 failures an hour. While this avoids a standard account lockout, it will cross the rolling 24-hour Excessive Failed Logins Threshold, flagging the distributed threat to your administrators.