STIGViewer Support

Okta must automatically disable accounts after a 35-day period of account inactivity.

Overview

Finding IDVersionRule IDIA ControlsSeverity
V-273188OKTA-APP-000090SV-273188r1098831_ruleCCI-000017medium
Description
Attackers that are able to exploit an inactive account can potentially obtain and maintain undetected access to an application. Owners of inactive accounts will not notice if unauthorized access to their user account has been obtained. Applications must track periods of user inactivity and disable accounts after 35 days of inactivity. Such a process greatly reduces the risk that accounts will be hijacked, leading to a data compromise. To address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access mechanisms that meet or exceed access control policy requirements. Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality. This policy does not apply to emergency accounts or infrequently used accounts. Infrequently used accounts are local login administrator accounts used by system administrators when network or normal login/access is not available. Emergency accounts are administrator accounts created in response to crisis situations. Satisfies: SRG-APP-000025, SRG-APP-000163, SRG-APP-000700
STIGDate
Okta Identity as a Service (IDaaS) Security Technical Implementation Guide2025-05-06

Related Frameworks

3 mappings across 5 frameworks
SCF0 mappings

No source states a mapping between these directly.

Also reachable in 3 hops (7) derived by us, not asserted by any source

Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.

IAC-02Identification & Authentication for Organizational Users
1.00
IAC-03Identification & Authentication for Non-Organizational Users
1.00
IAC-04Identification & Authentication for Devices
1.00
IAC-05Identification & Authentication for Third-Party Technology Assets, Applications and/or Services (TAAS)
1.00
IAC-15.3Disable Inactive Accounts
1.00
IAC-01.2Authenticate, Authorize and Audit (AAA)
0.50
IAC-09Identifier Management (User Names)
0.50
NIST 800-530 mappings

No source states a mapping between these directly.

Also reachable in 2 hops (71) derived by us, not asserted by any source

Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.

AC-10Concurrent Session Control
1.00
AC-12Session Termination
1.00
AC-17(10)Authenticate Remote Commands
1.00
AC-2Account Management
1.00
AC-2(1)Automated System Account Management
1.00
AC-2(10)Shared and Group Account Credential Change
1.00
AC-2(11)Usage Conditions
1.00
AC-2(2)Automated Temporary and Emergency Account Management
1.00
AC-2(3)Disable Accounts
1.00
AC-2(4)Automated Audit Actions
1.00

+61 more (top 10 by confidence shown)

NIST 800-1710 mappings

No source states a mapping between these directly.

Also reachable in 3 hops (2) derived by us, not asserted by any source

Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.

3.5.5
1.00
3.5.6
1.00
CCI3 mappings
NIST CSF 2.00 mappings

No source states a mapping between these directly.

Also reachable in 3 hops (5) derived by us, not asserted by any source

Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.

PR.AAIdentity Management, Authentication, and Access Control
0.50

Who does this work

6 NICE work roles and 5 EC-Council certifications.

This is an inference across published mappings, not a single claim by anyone. This check maps to a control, which maps to a Cybersecurity Framework outcome, which NIST assigns to the work roles below. EC-Council separately maps its certifications to those same roles.

A certification prepares someone for a role. It is not evidence that a holder is qualified, and neither NIST nor EC-Council has stated that any certification here addresses this check.

Work-role assignments published by NIST (NICE Framework Components 2.2.0 and the CSF 2.0 OLIR crosswalk). Certification mappings published by EC-Council.

Details

Check Text (C-273188r1098831_chk)

If Okta Services rely on external directory services for user sourcing, this is not applicable, and the connected directory services must perform this function. Go to Workflows >> Automations and verify that an Automation has been created to disable accounts after 35 days of inactivity. If the Okta configuration does not automatically disable accounts after a 35-day period of account inactivity, this is a finding.

Fix Text (F-77184r1098830_fix)

From the Admin Console: 1. Go to Workflow >> Automations and select "Add Automation". 2. Create a name for the Automation (e.g., "User Inactivity"). 3. Click "Add Condition" and select "User Inactivity in Okta". 4. In the duration field, enter 35 days and click "Save". 5 Click the edit button next to "Select Schedule". 6. Configure the "Schedule" field for "Run Daily" and set the "Time" field to an organizationally defined time to run this automation. Click "Save". 7. Click the edit button next to "Select group membership". 8. In the "Applies to" field, select the group "Everyone" by typing it into the field. Click "Save". 9. Click "Add Action" and select "Change User lifecycle state in Okta". 10. In the "Change user state to" field, select "Suspended" and click "Save". 11. Click the "Inactive" button near the top of the section screen and select "Activate".