v0.2.1-draft AI Drafted
Home / Guides / OneLogin

OneLogin Hardening Guide

Identity Last updated: 2026-08-08

Identity provider hardening for OneLogin including MFA policies, user security, and SmartFactor Authentication

Product Docs API Docs
Security Policies (MFA, lockout, session, IP)Authentication Factors
Code Packs: API Scripts
View:

Overview

OneLogin is a leading cloud identity and access management platform providing SSO and MFA to thousands of enterprises worldwide. As the authentication gateway for corporate applications, OneLogin security configurations directly impact access control for all integrated systems. Compromised identity providers can provide attackers with access to the entire SaaS ecosystem.

Intended Audience

  • Security engineers managing identity infrastructure
  • IT administrators configuring OneLogin
  • GRC professionals assessing IAM security
  • Third-party risk managers evaluating identity providers

How to Use This Guide

  • L1 (Crawl): Essential controls for all organizations
  • L2 (Walk): Enhanced controls for security-sensitive environments
  • L3 (Run): Strictest controls for regulated industries

Scope

This guide covers OneLogin administration console security, user policies, MFA configuration, and access controls.

Table of Contents

  1. User Security Policies
  2. Multi-Factor Authentication
  3. Admin & Access Controls
  4. Session & Network Security
  5. Monitoring & Compliance
  6. Compliance Quick Reference

1. User Security Policies

1.1 Configure Password Policy

Profile Level: L1 (Crawl)

Framework Control
CIS Controls 5.2
NIST 800-53 IA-5

Description

Configure password policies to enforce strong authentication requirements for OneLogin users.

Rationale

Why This Matters:

  • Weak or reused passwords are the most common entry point for credential stuffing and brute-force attacks against the identity provider
  • OneLogin authenticates access to every downstream SaaS app, so a single guessed password can cascade into the entire application portfolio
  • Account lockout thresholds blunt automated password-guessing tools before they succeed

Attack Prevented: Credential stuffing, brute-force password guessing, password reuse exploitation

ClickOps Implementation

Step 1: Access User Policies

  1. Navigate to: Security → Policies
  2. Select Default policy or create new policy

Step 2: Configure Password Settings

  1. Configure password requirements:
    • Minimum length: 12+ characters (14+ for L2)
    • Complexity requirements: Uppercase, lowercase, numbers, symbols
    • Password history: Prevent reuse of last 10 passwords
    • Password expiration: 90 days (or disable for modern approach)
  2. Configure lockout settings:
    • Maximum Invalid Login Attempts: 5 (OneLogin accepts a value from 3 to 10, or No limit)
    • Lock effective period: 30 minutes (OneLogin offers 15, 30, or 60 minutes, or Until Unlocked)

Correction — a setting this guide previously described does not exist. Earlier revisions instructed administrators to configure a “Reset counter: after 15 minutes” value. OneLogin’s user policy has no counter-reset interval. Per OneLogin’s user policies documentation, the invalid-attempt count resets on a successful sign-in or a password reset — not on a timer. The two real settings are Maximum Invalid Login Attempts and Lock effective period, both shown above. Source: OneLogin User Policies (KB0010420).

Step 3: Apply Policy

  1. Assign policy to users or groups
  2. Communicate changes to users
  3. Monitor compliance

Time to Complete: ~20 minutes

1.2 Configure Session Controls

Profile Level: L1 (Crawl)

Framework Control
CIS Controls 6.2
NIST 800-53 AC-12

Description

Configure session timeout and activity controls to limit exposure from idle sessions.

Rationale

Why This Matters:

  • Long-lived or idle sessions leave authenticated tokens available for theft on unattended or shared devices
  • Bounded session and idle timeouts shrink the window an attacker has to ride a hijacked session into connected applications
  • Forced re-authentication on sensitive apps ensures a stolen session cannot silently reach the most critical resources

Attack Prevented: Session hijacking, token replay, unauthorized access from unattended devices

ClickOps Implementation

Step 1: Configure Session Timeout

  1. Navigate to: Security → Policies → Select policy
  2. Configure session settings:
    • Session timeout: 8 hours (or less for L2)
    • Idle timeout: 15 minutes (L2: 5 minutes)
    • Force re-authentication: For sensitive apps

Step 2: Configure Session Controls

  1. Enable Single session enforcement if required
  2. Configure re-authentication for sensitive operations
  3. Enable session termination on logout

1.3 Enable Self-Service Password Reset

Profile Level: L1 (Crawl)

Framework Control
CIS Controls 5.2
NIST 800-53 IA-5

Description

Configure secure self-service password reset to reduce helpdesk burden while maintaining security.

Rationale

Why This Matters:

  • Password reset flows are a frequent target for social engineering and account takeover when identity proofing is weak
  • Requiring MFA and strong verification on reset prevents attackers from seizing accounts through the recovery path
  • Self-service reset removes helpdesk impersonation as an attack vector while keeping verification controls enforced

Attack Prevented: Account takeover via recovery flow, helpdesk social engineering, password reset abuse

ClickOps Implementation

Step 1: Enable Self-Service

  1. Navigate to: Security → Policies → Select policy
  2. Enable Self-service password reset

Step 2: Configure Reset Methods

  1. Configure recovery methods:
    • Security questions: 3+ questions required
    • Email verification: Send reset link
    • SMS verification: If enabled
  2. Require MFA for password reset (recommended)

Step 3: Enable reCAPTCHA on Account Recovery

  1. In the user policy, enable reCAPTCHA for the account recovery flow
  2. This blunts automated abuse of the recovery path — scripted enumeration and bulk reset attempts — which the MFA requirement alone does not stop, because the attacker never reaches the MFA step

Step 4: Set Security Questions

  1. Navigate to: Settings → Security Questions
  2. Configure custom security questions
  3. Require unique answers

1.4 Enable Compromised Credential Checking

Profile Level: L1 (Crawl)

Framework Control
CIS Controls 5.2
NIST 800-53 IA-5(1)

Description

Enable OneLogin’s compromised credential checks so users cannot set or reset a password that already appears in known breach data.

Rationale

Why This Matters:

  • Password complexity rules do not stop a user choosing a password that is already circulating in credential dumps — complexity and compromise are independent properties
  • OneLogin’s user policy exposes two distinct checks: Enforce compromised credential check, which evaluates the username and password pair, and Enforce compromised password check, which evaluates the password alone. The pair check catches the specific credential an attacker would replay against you; the password check catches broadly-known passwords regardless of account
  • Blocking the credential at the moment it is set or reset is the only enforcement point that prevents the exposure, rather than detecting it later
  • OneLogin fronts every downstream SaaS application, so one breached-and-reused password here cascades across the entire application portfolio

Attack Prevented: Credential stuffing, breach-replay attacks, password reuse across personal and corporate accounts

ClickOps Implementation

Step 1: Enable the Checks

  1. Navigate to: Security → Policies → select the user policy
  2. Enable Enforce compromised credential check (username + password pair)
  3. Enable Enforce compromised password check (password only)

Step 2: Roll Out

  1. Apply to all user policies, starting with policies covering administrators
  2. Prepare help-desk messaging: users will be refused at set/reset time and need to know why
  3. Confirm the policy is assigned to every user group, not just the default policy

Validation & Testing

  1. Attempt to set a well-known breached password on a test account and confirm it is refused
  2. Confirm the refusal occurs at both initial set and reset

1.5 Harden Remaining User Policy Settings

Profile Level: L2 (Walk)

Framework Control
CIS Controls 4.8, 5.3
NIST 800-53 AC-8, CM-7, AC-2

Description

Review and tighten the remaining user policy settings that are easy to leave at defaults — social sign-in, self-service app access, browser extension permissions, invitation-link lifetime, and the system use notification.

Rationale

Why This Matters:

  • Social Sign-In lets users authenticate to the corporate identity provider with a consumer account whose security posture — password, MFA, recovery — you do not control and cannot audit; unless there is a documented business case, it should be off
  • Portal App Store access lets users add applications to their portal themselves, which quietly moves application-access decisions out of the access-request process and into the hands of every user
  • Browser Extension permissions govern what the OneLogin extension may do on the endpoint; the extension handles credentials, so its permissions belong in the review rather than at whatever the default is
  • Invitation link timeout defaults to 24 hours; an unused invitation is an unclaimed account-creation token, and a shorter window reduces the chance one is intercepted and redeemed by someone else
  • System use notification is the banner presented at sign-in; several regulated frameworks require it, and it is trivially configured and routinely forgotten

Attack Prevented: Account takeover via a compromised consumer identity, unreviewed application access, over-permissioned browser extension, interception and redemption of stale invitation links

ClickOps Implementation

Step 1: Review Sign-In and Access Settings

  1. Navigate to: Security → Policies → select the user policy
  2. Disable Social Sign-In unless a documented business case exists
  3. Disable or restrict Portal App Store access so application additions flow through the access-request process
  4. Review Browser Extension permissions and grant only what the deployment requires

Step 2: Tighten Invitations and Notices

  1. Reduce the invitation link timeout below the 24-hour default to the shortest period your onboarding process tolerates
  2. Configure the System use notification banner text to your organization’s required wording

Validation & Testing

  1. Confirm the social sign-in option no longer appears at the portal login
  2. Confirm an invitation link expires at the configured interval
  3. Confirm the system use notification renders at sign-in

2. Multi-Factor Authentication

2.1 Enforce MFA for All Users

Profile Level: L1 (Crawl)

Framework Control
CIS Controls 6.5
NIST 800-53 IA-2(1)

Description

Require multi-factor authentication for all users accessing OneLogin.

Rationale

Why This Matters:

  • Single-factor authentication is insufficient for identity providers
  • MFA prevents account takeover from credential theft
  • OneLogin is the authentication gateway to every integrated application, so an account takeover here is an account takeover everywhere
  • Required for compliance with most frameworks

Attack Prevented: Credential theft, phishing, password-only account takeover, credential stuffing against the identity provider

ClickOps Implementation

Step 1: Configure Authentication Factors

  1. Navigate to: Security → Authentication Factors
  2. Click New Auth Factor
  3. Add desired factors:
    • OneLogin Protect: Push notification app (recommended)
    • Google Authenticator: TOTP app
    • WebAuthn/FIDO2: Hardware keys (most secure)
    • SMS: Not recommended but available
    • Email: Not recommended but available

Step 2: Configure MFA Policy

  1. Navigate to: Security → Policies → Select policy
  2. Enable OTP Auth Required
  3. Configure MFA settings:
    • Require at login: Always
    • Allowed factors: Select approved factors
    • Remember device: 7-30 days (or never for L3)

Step 3: Apply MFA Policy

  1. Apply policy to all users
  2. Set grace period for enrollment
  3. Monitor compliance

Time to Complete: ~30 minutes

2.2 Configure SmartFactor Authentication

Profile Level: L2 (Walk)

Framework Control
CIS Controls 6.5
NIST 800-53 IA-2(13)

Description

Enable SmartFactor Authentication for risk-based adaptive MFA.

Rationale

Why This Matters:

  • Adaptive MFA uses machine learning to evaluate risk
  • Low-risk logins can skip MFA step-up for better UX
  • High-risk logins require additional verification
  • Protects against brute force and phishing attacks

Attack Prevented: Account takeover from anomalous locations and devices, credential stuffing, brute-force sign-in attempts, phishing follow-on access

Naming note: OneLogin’s product name for this capability is SmartFactor Authentication, but at the user-policy level the setting is labelled Smart MFA — the control that suppresses the MFA prompt when the evaluated risk score is at or below a configured level. Expect to see the policy-level label rather than the product name when configuring it, and read “suppress when risk ≤ level” carefully: the setting decides when MFA is not required.

Prerequisites

  • OneLogin Expert plan or higher

ClickOps Implementation

Step 1: Enable SmartFactor / Smart MFA

  1. Navigate to: Security → Policies → Select policy
  2. Enable Smart MFA (SmartFactor Authentication)
  3. Configure the risk level at or below which the MFA prompt is suppressed — start conservative

Step 2: Configure Risk Signals

  1. Configure risk assessment:
    • Login location
    • Device fingerprint
    • Time of access
    • Network reputation
  2. Set response actions for risk levels:
    • Low risk: No additional MFA
    • Medium risk: Require MFA
    • High risk: Block and alert

Step 3: Review and Tune

  1. Monitor SmartFactor decisions
  2. Adjust thresholds based on false positives
  3. Review blocked attempts

2.3 Require Phishing-Resistant MFA for Admins

Profile Level: L2 (Walk)

Framework Control
CIS Controls 6.5
NIST 800-53 IA-2(6)

Description

Require WebAuthn/FIDO2 hardware keys for administrator accounts.

Rationale

Why This Matters:

  • Administrators hold the keys to the entire identity platform, making their accounts the highest-value target for attackers
  • WebAuthn/FIDO2 keys are bound to the origin and cannot be replayed, defeating phishing and adversary-in-the-middle proxies that bypass push and TOTP factors
  • Disabling SMS, email, and TOTP for admins removes the weaker factors attackers prefer to intercept or fatigue

Attack Prevented: Phishing, adversary-in-the-middle, MFA fatigue, SIM swapping, admin account takeover

ClickOps Implementation

Step 1: Create Admin MFA Policy

  1. Navigate to: Security → Policies
  2. Create new policy: Admin MFA Policy

Step 2: Configure WebAuthn Requirement

  1. Configure MFA factors:
    • WebAuthn/FIDO2: Required
    • Disable: SMS, email, TOTP
  2. Enable Require phishing-resistant MFA

Step 3: Apply to Admins

  1. Create admin group if not exists
  2. Assign Admin MFA Policy to admin group
  3. Document hardware key distribution

2.4 Select the Right Login Flow

Profile Level: L2 (Walk)

Framework Control
CIS Controls 6.3, 6.5
NIST 800-53 IA-2, AC-7

Description

Choose the user policy’s login flow deliberately. OneLogin documents three orderings of the authentication steps, and the order — not just which factors are enabled — determines what an attacker can attempt.

Rationale

Why This Matters:

  • In the Standard flow (identifier → password → MFA), password evaluation happens before MFA, so an attacker who knows a username can guess passwords freely and receives feedback on each attempt
  • In the Brute-Force Defense flow (identifier → MFA → password), the user must satisfy MFA before the password is evaluated at all — password guessing never reaches credential evaluation, which removes the oracle that makes spraying and stuffing productive
  • In the Passwordless flow (identifier → MFA), there is no password in the flow to guess, phish, or reuse
  • The choice is a policy-level decision with real usability consequences, so it belongs in a deliberate review rather than being inherited from the default

Attack Prevented: Password spraying, credential stuffing, brute-force password guessing, phishing of a password that the flow never requests

ClickOps Implementation

Step 1: Review the Current Flow

  1. Navigate to: Security → Policies → select the user policy
  2. Identify which login flow the policy currently uses

Step 2: Select the Flow Per Population

Flow Order When to use
Standard Identifier → Password → MFA Default; familiar, but exposes password evaluation to unauthenticated attempts
Brute-Force Defense Identifier → MFA → Password Populations under credential-stuffing or spraying pressure, and administrator policies
Passwordless Identifier → MFA Populations fully enrolled in phishing-resistant factors
  1. Apply Brute-Force Defense or Passwordless to administrator policies first
  2. Pilot with one group before broad rollout — the changed prompt order is visible to users

Validation & Testing

  1. Sign in as a member of the policy and confirm the prompts appear in the expected order
  2. On a Brute-Force Defense policy, confirm an incorrect password is only evaluated after MFA succeeds

3. Admin & Access Controls

3.1 Implement Delegated Administration

Profile Level: L1 (Crawl)

Framework Control
CIS Controls 5.4
NIST 800-53 AC-6(1)

Description

Configure delegated administration to implement least privilege for admin access.

Rationale

Why This Matters:

  • Super-user accounts can alter any policy, user, or app integration, so broad admin grants dramatically expand the blast radius of a compromise
  • Scoped custom roles ensure helpdesk and tier-1 staff hold only the permissions their job requires
  • Limiting the number of full administrators reduces the set of accounts an attacker can target for total control

Attack Prevented: Privilege escalation, lateral movement, insider misuse, blast-radius expansion

ClickOps Implementation

Step 1: Review Admin Roles

  1. Navigate to: Users → Roles
  2. Review built-in roles:
    • Super user: Full access (limit to 2-3)
    • User admin: User management
    • App admin: Application management
    • Help desk: Limited support access

Step 2: Create Custom Roles

  1. Click New Role
  2. Configure role permissions:
    • Name: Tier 1 Support
    • Permissions: Password reset, unlock accounts
  3. Apply principle of least privilege

Step 3: Assign Roles

  1. Assign appropriate roles to administrators
  2. Document role assignments
  3. Regular review of admin access

3.2 Configure IP Address Allowlisting

Profile Level: L2 (Walk)

Framework Control
CIS Controls 13.5
NIST 800-53 AC-17, SC-7

Description

Restrict access to OneLogin from approved IP addresses.

Rationale

Why This Matters:

  • Restricting logins to corporate and VPN egress IPs denies attackers access even when they hold valid stolen credentials
  • Network-based restrictions add a control that cannot be defeated by phishing the password or a one-time code
  • Step-up or block responses for unknown IPs flag and contain anomalous access attempts from unexpected locations

Attack Prevented: Credential theft exploitation, remote access from untrusted networks, geographic-anomaly logins

ClickOps Implementation

Step 1: Configure IP Restrictions

  1. Navigate to: Security → Policies → Select policy
  2. Enable IP address restrictions
  3. Add allowed IP addresses/ranges:
    • Corporate network
    • VPN egress IPs
    • Trusted partner IPs

Step 2: Configure Response

  1. Configure action for unauthorized IPs:
    • Block access: Deny login
    • Require MFA: Step-up authentication
    • Alert: Notify administrators

Step 3: Test and Validate

  1. Test from allowed IPs
  2. Verify blocked from unauthorized IPs
  3. Document emergency procedures

3.3 Protect Privileged Accounts

Profile Level: L1 (Crawl)

Framework Control
CIS Controls 5.4
NIST 800-53 AC-6

Description

Implement additional protections for privileged administrator accounts.

Rationale

Why This Matters:

  • Privileged accounts are the primary objective of targeted attacks because they control the entire identity fabric
  • Separate admin and daily-use accounts prevent routine browsing or email compromise from exposing administrative power
  • Shorter timeouts, mandatory MFA, and enhanced logging on these accounts detect and limit misuse faster

Attack Prevented: Admin account takeover, privilege abuse, lateral movement, standing-privilege exploitation

ClickOps Implementation

Step 1: Identify Privileged Accounts

  1. Navigate to: Users → Filter by admin roles
  2. Document all privileged accounts
  3. Verify business need for each

Step 2: Apply Enhanced Protections

  1. Create dedicated policy for admins
  2. Configure:
    • Shorter session timeout
    • Mandatory MFA at every login
    • IP restrictions (if possible)
    • Enhanced logging

Step 3: Implement Separation of Duties

  1. Use separate accounts for admin vs. daily work
  2. Require approval for privilege changes
  3. Regular access reviews

Code Implementation

Code Pack: API Script
hth-onelogin-3.03-privileged-role-inventory.sh View source on GitHub ↗ 
# Client-credentials access token (valid 10 hours).
ACCESS_TOKEN=$(curl -sf "${BASE_URL}/auth/oauth2/v2/token" \
  -X POST \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  --data-urlencode 'grant_type=client_credentials' \
  --data-urlencode "client_id=${ONELOGIN_CLIENT_ID}" \
  --data-urlencode "client_secret=${ONELOGIN_CLIENT_SECRET}" | jq -r '.access_token')
# Enumerate every role with its admins and members. Document each admin
# assignment, verify the business need, and flag roles whose admin list
# has grown beyond the documented set.
curl -sf "${BASE_URL}/api/2/roles?fields=admins,users" \
  -H "Authorization: bearer ${ACCESS_TOKEN}" |
  jq -r '.[] | "role=\(.id) name=\(.name // "-") admins=\((.admins // []) | length) users=\((.users // []) | length) admin_ids=\((.admins // []) | map(tostring) | join(","))"'
# Resolve a privileged user ID from the inventory above to a named account
# (v2 Users API). Repeat per admin ID and record the mapping in the
# privileged-account register this control requires.
ADMIN_USER_ID="12345678"
curl -sf "${BASE_URL}/api/2/users?user_ids=${ADMIN_USER_ID}&fields=id,username,email,state,status,last_login" \
  -H "Authorization: bearer ${ACCESS_TOKEN}" | jq .

3.4 Automatically Suspend Inactive Users

Profile Level: L1 (Crawl)

Framework Control
CIS Controls 5.3
NIST 800-53 AC-2(3)

Description

Configure OneLogin’s user policy to automatically suspend accounts that have not been used for a defined period, so dormant accounts stop being valid entry points into every connected application.

Rationale

Why This Matters:

  • Dormant accounts are the accounts nobody notices: no user reports the anomalous login, and no manager flags the access during review
  • An identity-provider account grants access to every application assigned to it, so a forgotten account is a forgotten key to the whole portfolio
  • Automatic suspension closes the offboarding gaps that manual deprovisioning misses — contractors, transfers, service-desk test accounts, and accounts created for projects that ended
  • OneLogin’s documented default inactivity period is 90 days; treat that as the starting point and tighten it for privileged populations

Attack Prevented: Dormant-account takeover, persistence through forgotten accounts, exploitation of incomplete offboarding

ClickOps Implementation

Step 1: Enable Inactivity Suspension

  1. Navigate to: Security → Policies → select the user policy
  2. Enable automatic suspension of inactive users
  3. Set the inactivity period — the documented default is 90 days; shorten it for administrator and contractor policies

Step 2: Handle the Exceptions Deliberately

  1. Identify accounts that legitimately sign in rarely (break-glass, seasonal staff) and document them rather than exempting the whole policy
  2. Define the reactivation process so suspension does not become an outage

Code Implementation

Code Pack: API Script
hth-onelogin-3.04-inactive-users.sh View source on GitHub ↗ 
# Client-credentials access token (valid 10 hours).
ACCESS_TOKEN=$(curl -sf "${BASE_URL}/auth/oauth2/v2/token" \
  -X POST \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  --data-urlencode 'grant_type=client_credentials' \
  --data-urlencode "client_id=${ONELOGIN_CLIENT_ID}" \
  --data-urlencode "client_secret=${ONELOGIN_CLIENT_SECRET}" | jq -r '.access_token')
# List accounts whose last login predates the inactivity cutoff.
# last_login_until is a documented v2 List Users filter (ISO8601).
# 90 days mirrors OneLogin's documented default inactivity period —
# tighten the window for admin and contractor policies.
CUTOFF=$(date -u -d "90 days ago" +%Y-%m-%dT%H:%M:%SZ 2>/dev/null || date -u -v-90d +%Y-%m-%dT%H:%M:%SZ)

curl -sf -G "${BASE_URL}/api/2/users" \
  --data-urlencode "last_login_until=${CUTOFF}" \
  --data-urlencode "fields=id,username,email,state,status,last_login" \
  -H "Authorization: bearer ${ACCESS_TOKEN}" |
  jq -r '.[] | [.id, .username, (.email // "-"), (.last_login // "never"), .status, .state] | @tsv'
# Accounts created before the cutoff that have never signed in — unclaimed
# accounts are unclaimed credentials and belong in the same review.
curl -sf -G "${BASE_URL}/api/2/users" \
  --data-urlencode "created_until=${CUTOFF}" \
  --data-urlencode "fields=id,username,email,created_at,last_login" \
  -H "Authorization: bearer ${ACCESS_TOKEN}" |
  jq -r '.[] | select(.last_login == null) | [.id, .username, (.email // "-"), .created_at] | @tsv'

Validation & Testing

  1. Review the user list for suspended accounts after the first policy interval and confirm the suspensions are expected
  2. Confirm a suspended account cannot authenticate to a downstream application

4. Session & Network Security

4.1 Configure TLS Requirements

Profile Level: L1 (Crawl)

Framework Control
CIS Controls 3.10
NIST 800-53 SC-8

Description

Ensure all OneLogin communications use strong TLS encryption.

Rationale

Why This Matters:

  • Authentication traffic, SAML assertions, and API calls carry credentials and session tokens that are exposed if transport is unencrypted or downgraded
  • Enforcing TLS 1.2+ prevents attackers on the network path from intercepting or tampering with login flows
  • Strong transport encryption is a baseline requirement for protecting identity data in transit and meeting compliance mandates

Attack Prevented: Man-in-the-middle interception, protocol downgrade, credential and token sniffing

Validation

  1. Verify OneLogin portal uses TLS 1.2+
  2. Check SAML connections use HTTPS
  3. Validate API connections are encrypted

4.2 Configure Brute Force Protection

Profile Level: L1 (Crawl)

Framework Control
CIS Controls 6.3
NIST 800-53 AC-7

Description

Configure account lockout and brute force protection.

Rationale

Why This Matters:

  • Without lockout thresholds, attackers can run unlimited automated password-guessing attempts against accounts
  • Lockout and counter-reset settings slow credential-guessing tools enough to make brute force impractical
  • Login anomaly detection and alerting surface ongoing attacks so responders can block malicious sources

Attack Prevented: Brute-force attacks, password spraying, credential stuffing

ClickOps Implementation

Step 1: Configure Lockout Policy

  1. Navigate to: Security → Policies → Select policy
  2. Configure lockout settings:
    • Maximum Invalid Login Attempts: 5 (valid range 3-10, or No limit)
    • Lock effective period: 30 minutes (options: 15, 30, 60 minutes, or Until Unlocked)
  3. There is no counter-reset interval to configure — OneLogin resets the invalid-attempt count on a successful sign-in or a password reset. See the correction callout in 1.1.

Step 2: Enable Detection

  1. Enable login anomaly detection
  2. Configure alerts for repeated failures
  3. Block known malicious IPs

4.3 Configure Device Trust

Profile Level: L2 (Walk)

Framework Control
CIS Controls 13.7
NIST 800-53 AC-17

Description

Implement device trust policies to verify device security posture.

Rationale

Why This Matters:

  • Allowing logins only from domain-joined or managed devices stops attackers using stolen credentials on unmanaged hardware
  • Device posture checks ensure authenticating endpoints meet security baselines before granting access
  • Binding access to trusted devices adds a factor that phished passwords and codes alone cannot satisfy

Attack Prevented: Credential theft exploitation, unmanaged-device access, endpoint compromise propagation

ClickOps Implementation

Step 1: Enable Desktop SSO

  1. Navigate to: Security → Desktop SSO
  2. Configure device trust requirements
  3. Deploy OneLogin desktop agent

Step 2: Configure Device Policies

  1. Configure device requirements:
    • Domain-joined devices
    • Certificate validation
    • Managed devices only

5. Monitoring & Compliance

5.1 Enable Audit Logging

Profile Level: L1 (Crawl)

Framework Control
CIS Controls 8.2
NIST 800-53 AU-2

Description

Enable and monitor audit logs for security events.

Rationale

Why This Matters:

  • Without comprehensive logs, account compromise and admin abuse can occur undetected and cannot be investigated after the fact
  • Capturing login, MFA, and configuration-change events provides the forensic trail needed for incident response
  • Exporting logs to a SIEM enables correlation, alerting, and retention beyond the platform’s native window

Attack Prevented: Undetected intrusion, log tampering, delayed breach discovery

ClickOps Implementation

Step 1: Access Event Logs

  1. Navigate to: Activity → Events
  2. Review login and admin events
  3. Export logs for SIEM

Step 2: Configure SIEM Integration

  1. Navigate to: Settings → SIEM Integration
  2. Configure log export:
    • Splunk
    • AWS S3
    • Custom webhook
  3. Verify log delivery

Key Events to Monitor:

  • Failed login attempts
  • Admin configuration changes
  • MFA enrollment changes
  • Password resets
  • User provisioning/deprovisioning

Code Implementation

Code Pack: API Script
hth-onelogin-5.01-events-export.sh View source on GitHub ↗ 
# Client-credentials access token (valid 10 hours).
ACCESS_TOKEN=$(curl -sf "${BASE_URL}/auth/oauth2/v2/token" \
  -X POST \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  --data-urlencode 'grant_type=client_credentials' \
  --data-urlencode "client_id=${ONELOGIN_CLIENT_ID}" \
  --data-urlencode "client_secret=${ONELOGIN_CLIENT_SECRET}" | jq -r '.access_token')
# Export events for a time window to newline-delimited JSON for the SIEM.
# since/until take ISO 8601 timestamps; add &event_type_id=<id> to filter to
# a single event type (see the Events API docs for the event type catalog).
SINCE="2026-08-01T00:00:00Z"
UNTIL="2026-08-08T00:00:00Z"
OUT="onelogin_events.ndjson"
: > "${OUT}"

URL="${BASE_URL}/api/1/events?since=${SINCE}&until=${UNTIL}"
while [ -n "${URL}" ] && [ "${URL}" != "null" ]; do
  PAGE=$(curl -sf "${URL}" -H "Authorization: bearer:${ACCESS_TOKEN}")
  echo "${PAGE}" | jq -c '.data[]' >> "${OUT}"
  URL=$(echo "${PAGE}" | jq -r '.pagination.next_link')
done
echo "Exported $(wc -l < "${OUT}") events to ${OUT}"
# Quick console review: most recent events with actor, target, and source IP.
curl -sf "${BASE_URL}/api/1/events?limit=50&sort=-id" \
  -H "Authorization: bearer:${ACCESS_TOKEN}" |
  jq -r '.data[] | [.created_at, .event_type_id, (.user_name // "-"),
                    (.actor_user_name // "-"), (.ipaddr // "-"), (.app_name // "-")] | @tsv'

5.2 Configure Security Alerts

Profile Level: L1 (Crawl)

Framework Control
CIS Controls 8.11
NIST 800-53 SI-4

Description

Configure alerts for security-relevant events.

Rationale

Why This Matters:

  • Real-time alerts on failed logins, privilege changes, and policy edits shrink the time attackers operate unnoticed
  • Notifying responders of unusual login locations and admin actions enables rapid containment before damage spreads
  • Alerting on policy modifications detects attempts to weaken security controls from within

Attack Prevented: Delayed incident response, stealthy privilege escalation, undetected configuration tampering

ClickOps Implementation

Step 1: Configure Alert Rules

  1. Navigate to: Settings → Alerts
  2. Create alert rules for:
    • Multiple failed logins
    • Admin privilege changes
    • Policy modifications
    • Unusual login locations

Step 2: Configure Notification

  1. Set notification recipients
  2. Configure escalation procedures
  3. Test alert delivery

6. Compliance Quick Reference

SOC 2 Trust Services Criteria Mapping

Control ID OneLogin Control Guide Section
CC6.1 MFA enforcement 2.1
CC6.1 Password policy 1.1
CC6.2 Delegated admin 3.1
CC6.6 IP allowlisting 3.2
CC7.2 Audit logging 5.1

NIST 800-53 Rev 5 Mapping

Control OneLogin Control Guide Section
IA-2(1) MFA 2.1
IA-2(13) Adaptive MFA 2.2
IA-5 Password policy 1.1
AC-6(1) Least privilege 3.1
AU-2 Audit logging 5.1

Appendix A: Plan Compatibility

Feature Starter Advanced Professional Expert
SSO ✅ ✅ ✅ ✅
MFA Basic ✅ ✅ ✅
SmartFactor ❌ ❌ ❌ ✅
Delegated Admin ❌ ❌ ✅ ✅
Custom Policies ❌ ✅ ✅ ✅
SIEM Integration ❌ ❌ ✅ ✅

Appendix B: References

Official OneLogin Documentation:

API Documentation:

Compliance Frameworks:

  • SOC 1 Type II, SOC 2 Type II, ISO 27001, ISO 27017, ISO 27018, HIPAA, GDPR

Security Incidents:

  • May 2017: Threat actor used a stolen AWS key to access OneLogin’s U.S. data center infrastructure for approximately seven hours, compromising database tables containing user data, app configurations, and encryption keys. OneLogin could not rule out the attacker’s ability to decrypt customer data. — Krebs on Security Report

Changelog

Date Version Maturity Changes Author
2026-08-08 0.2.1 draft Add REST API Code Packs: 3.3 (Roles v2 admin inventory + privileged-user resolution), 3.4 (Users v2 last_login_until dormant-account and never-logged-in detection), 5.1 (Events v1 SIEM export with cursor pagination) — endpoints, params, and auth header formats verified against developers.onelogin.com Claude Code (Fable 5)
2026-08-08 0.2.0 draft Correct 1.1 and 4.2 — the “reset counter after 15 minutes” setting does not exist (real settings are Maximum Invalid Login Attempts and Lock effective period); add compromised credential checking (1.4), remaining user policy hardening (1.5), login flow selection incl. Brute-Force Defense (2.4), and automatic suspension of inactive users (3.4); note the policy-level “Smart MFA” label in 2.2; add reCAPTCHA on account recovery to 1.3; add missing Attack Prevented lines to 2.1 and 2.2; drop compliance marketing references Claude Code (Opus 5)
2026-06-29 0.1.1 draft Add cheat-sheet Description and Rationale for all controls Claude Code (Opus 4.8)
2025-02-05 0.1.0 draft Initial guide with MFA, policies, and admin controls Claude Code (Opus 4.5)

Source coverage note: This revision is built on OneLogin’s Tier 1 user policies documentation (KB0010420, published 2025-11-17). No Tier 2 benchmark coverage was confirmed for OneLogin (no CIS Benchmark, DISA STIG, or CISA SCuBA baseline located for this product). Tier 3/4 independent research was not surveyed for this revision. No product end-of-life or rename transition is asserted here: One Identity’s ownership of OneLogin is visible publicly, but no citable transition announcement was verified.

Contributing

Found an issue or want to improve this guide?