Account inactivity can be defined as a user account that has not been accessed or logged into Okta for a specified period. Establishing a process to handle account inactivity is crucial for enhancing security and addressing regulatory and compliance issues.
Some common reasons for account inactivity are:
- The employee left the organization, but the account wasn’t deactivated
- The employee is on extended leave
- The employee has never logged in
- The employee has not logged in recently
- The employee might change roles or no longer require access to the Okta-protected application
- Contractors or temporary staff whose accounts remain active beyond their contract duration
Not implementing an account inactivity policy within the organization can increase security risk because attackers can exploit dormant accounts and lead the organization to violate regulatory frameworks by failing to deactivate inactive accounts.
Okta Implementation Details
The IAM team needs to respond by establishing an Inactivity Workflow, which can take any of the following actions:
- Automatically flag inactive accounts after a defined threshold (e.g., 30, 45,60, 90 days)
- Notify users and managers before deactivating accounts
- Automatically suspend or deactivate accounts after a confirmed inactivity period
- Automatically delete suspended accounts after a period
Two essential definitions to establish inactivity are:
- Inactivity Period:
- The inactivity period is a configurable number of days set within the Okta automation. For example, automation might be set to trigger after 30, 60, or 90 days of inactivity.
- Last Login Date: Okta checks the last login date of an active user against the defined inactivity period to determine if they should be considered inactive.
If a user hasn’t logged into Okta for 45 days, and the automation is set to trigger after 45 days of inactivity, the automation will be initiated.
Within Okta, you can implement an inactivity process in multiple ways depending on your organization’s requirements and the level of customization the team wants to pursue. As part of this initial post, we will mention two out-of-the-box features provided by Okta.
- Using Okta Automation
- Using Okta Workflow
Okta Automation
Okta automations enable you to prepare and respond to situations that occur during the lifecycle of end users who are assigned to an Okta group.
In Okta, user inactivity is defined as an active user not logging into Okta for a specified number of days. This definition is used in Okta automations to trigger actions like sending alerts or deactivating accounts when users haven’t engaged with the platform for a set duration.
Okta Automations for user inactivity rely on successful logins to the Okta dashboard (eventType eq “user.session.start”). If a user accesses apps like Google Gmail directly without logging into Okta, that activity doesn’t count. As a result, inactivity-based automations (e.g., lifecycle state changes) may trigger even if the user is actively using downstream applications.
Okta Workflow
Identify Inactive Okta User
Out of the box, Okta provides a workflow template to identify Inactive Okta users. This template searches for all users in an Okta tenant whose last login date was before a specific date and writes information about those users to a table in Workflows. The data in the table can be exported to a CSV file as a download or as an attachment to an email for periodic reporting.
Okta GitHub Repository: https://github.com/okta/workflows-templates/tree/master/workflows/identify_inactive_okta_users
Security Frameworks
Establish a recurrent Okta Inactivity process for your organization to address Inactive Account Management for the following Security Frameworks.
| Framework | Control ID / Reference | Requirement Summary |
| CIS Controls v8 | Control 5.3 – Disable Dormant Accounts | Delete or disable any dormant accounts after a period of 45 days of inactivity, where supported. |
| NIST SP 800-53 | AC-2(3) – Disable Inactive Accounts | Disable user accounts after a defined period of inactivity; recommends automation. |
| ISO/IEC 27001:2022 | Clause 5.15 – Access Control | Access rights must be reviewed; inactive accounts should be removed or disabled. |
| PCI DSS v4.0 | 8.2.6 – Account Management | Inactive user accounts must be disabled/removed after no more than 90 days. |
| HIPAA Security Rule | §164.308(a)(3)(ii)(C) | Organizations must implement termination procedures, including for inactive accounts. |
| SOX (ITGC Controls) | Best Practice / Audit Expectation | Access reviews must include disabling dormant accounts to prevent control deficiencies. |
| FedRAMP (based on NIST) | AC-2(3) | Follows NIST SP 800-53 guidance to automate disabling inactive accounts. |
Conclusion
Implementing an inactive account management process strengthens security by reducing potential attack vectors, supports compliance with regulatory standards, enhances administrative efficiency, optimizes licensing costs, and promotes consistent, automated enforcement across the organization.
- Minimizing Security Exposure:
- Dormant accounts pose a security risk. If credentials are compromised and the account remains active without oversight, attackers could leverage it to gain unauthorized access to systems or data.
- Ensuring Compliance and Audit Readiness:
- Security frameworks and regulatory standards often mandate that organizations maintain current user account inventories and promptly suspend, disable or remove inactive accounts to demonstrate proper access control and governance.
- Streamlined User Management:
- Removing inactive accounts simplifies administration by reducing clutter, enabling more efficient permission management, issue resolution, and periodic access reviews.
- Licensing and Cost Efficiency:
- Suspending, disabling, or removing inactive accounts helps avoid unnecessary licensing costs, ensuring the organization only pays for actively used accounts and services.
- Consistent Policy Enforcement:
- Automating inactivity-based account controls ensures policies are applied uniformly and reliably, minimizing reliance on manual reviews and reducing the risk of oversight or inconsistency.
Additional Content
Okta Documentation
Help: Automations
Okta Help Center
Knowledge base: Under which Condition is a User Considered “Inactive” in Okta Automations
Youtube Help Center
In this video you will learn how to identify inactive Okta users (users who haven’t logged-in for x-number of days) and save these users into a Workflows table.
Gabriel Magarino
Gabriel Magarino – Senior Security Manager | IAM Evangelist - Experienced leader with over 20 years in the IT and cybersecurity industry, specializing in Identity & Access Management. Expert in Okta, One Identity, SailPoint (IdentityIQ & IdentityNow), OneLogin, Delinea, and CyberArk. Passionate about exploring IAM and emerging technologies, coaching, and training IAM teams. Holds a Master’s in Computer Science and multiple certifications, including Okta Professional & Administration, One Identity Architect & Instructor, SailPoint Identity Now, ITIL, Scrum Master, among others. Currently pursuing a PhD with a focus on Computer Science and Artificial Intelligence.