Administration
Okta and concurrent session-limiting security requirements
Brandon Iske

Access control is a cornerstone of cybersecurity. In the modern world of web applications, Identity, Credential, and Access Management (ICAM) introduces a set of security tools, policies, and systems that help organizations manage, monitor, and secure access to their infrastructure. 


Okta and modern Identity Providers (IdPs) supply access management solutions to efficiently and robustly manage and log end-user activity and security events, meeting today’s security requirements while enabling the experience all users expect.


Common challenges

Identity management has substantially evolved in today’s landscape, particularly with users now using multiple devices simultaneously.


Imagine an everyday use case: During your work day, you’ve previously logged in to your email account on your workstation. Later on, you try accessing your email account on your phone, but cannot due to the existing workstation email session.


AC-10 - Concurrent Session Control

The National Institute of Standards and Technology (NIST) Security and Privacy Controls for Information Systems and Organizations NIST 800-53 introduces a common industry challenge due to security control Access Control (AC)-10 - Concurrent Session Control. Captured in the publication as follows:


Control: Limit the number of concurrent sessions for each [Assignment: organization-defined account and/or account type] to [Assignment: organization-defined number]. 


Discussion: Organizations may define the maximum number of concurrent sessions for system accounts globally, by account type, by account, or any combination thereof. For example, organizations may limit the number of concurrent sessions for system administrators or other individuals working in particularly sensitive domains or mission-critical applications. Concurrent session control addresses concurrent sessions for system accounts. It does not, however, address concurrent sessions by single users via multiple system accounts. 


Okta is here to help

Okta’s back-end takes a Zero Trust contextual approach to validate each session with granular access sign-on policies (ASOP). When a user attempts to authenticate, Okta evaluates various attributes for each login or access attempt, including behavioral detections such as existing sessions, IPs, and locations, in addition to customized configurations. The attribute data is then fed into Okta's risk engine, which allows administrators to determine what action(s) are prompted when someone triggers a high-risk login, such as requiring step-up authentication, denying access, or other.


To address the challenge of concurrent sessions in relation to NIST800-53 Access Control (AC-10), Okta has collaborated in partnership with the US Department of Defense (DoD) and Defense Information Systems Agency (DISA) to develop the recently released Okta Identity-as-a-Service (IDaaS) Security Technical Implementation Guide (STIG) 1.1.


Risk Mitigation Statement

Okta IDaaS supports many identity use cases where users typically expect to access resources from multiple browsers and devices. Okta provides visibility for end users to manage their authenticated sessions and the ability to report and/or terminate unknown sessions. Since Okta manages the distribution of access tokens, the onus of limiting concurrent connections would logically fall on the downstream application, if required. The Okta IDaaS STIG also addresses this in OKTA-APP-000010, marking the AC-10 requirement as Not Applicable (N/A).


Helpful resources

Okta continues to prioritize our customers and their evolving security program needs. To learn more about configuring session control in your Okta org, visit the following:

  • 0 Likes
  • 0 Comments
  • 208 Views
Skip Feed

Nothing here yet?

Log in to post to this feed.

End of Feed
Nothing here yet?Log in to post to this feed.