Okta is proud to announce the latest version (1.1) of the Okta Security Technical Implementation Guide (STIG), which provides U.S. government agencies additional security hardening recommendations related to network security and non-human identities.

First published by Okta and the U.S. Defense Information Systems Agency (DISA) in March 2025, the Okta Identity as a Service (IDaaS) STIG provides instrumental hardening guidance for identity and security practitioners.

The new checks introduced in version 1.1 are critical for securing service accounts, integrations, users, automation, and AI agents. This updated guidance provides security mitigations in addition to protocols like DPoP and Cross App Access.

With the updated version of the STIG, we introduce five new checks. These checks are important in the efforts to protect NHI use cases as well as aligning with the latest version of the DoD Cloud Computing Security Requirements Guide (CC SRG). One update to the CC SRG is: 

Section 5.9.3.1

“…PaaS/SaaS offerings must ensure that exposing any allowlisted services does not enable all Mission Owner or tenants internet facing access by default. This can be accomplished through implementing internal firewall rules, proxies or other solutions that are compatible with the CSOs specific infrastructure and offerings.”

For commercial entities reading this, it essentially means don’t open your services to the internet by default. Our updated guidance provides the checks to help lock down access by IP, IP Range, or Geographic location. In addition to the network restrictions, we added a check to help block ‘anonymized proxies’, which are often a source of malicious traffic. 

The FedRAMP Program Management Office (PMO) requires Cloud Service Providers (CSPs) to provide “Recommended Secure Configuration” related to their service offerings. The Okta IDaaS STIG is Okta’s “Recommended Secure Configuration.” The benefit of doing a STIG is the additional independent validation and assessment provided by DISA. Our collaboration with DISA has been extremely valuable. We share the mission of helping our customers become as secure as possible. 

Commercial customers should take a risk-based approach to determine which STIGs to apply. We understand that commercial CSPs and vendors will often pursue maximum compatibility for customers, nevertheless these additional checks can be used for all privileged access (administrative and NHI) use cases. These are the kinds of checks that Okta leveraged to help prevent attacks, such as the recent Salesloft Drift and Gainsight attacks. These checks are specific to Okta’s offerings, but the same approach should be used for other service offerings. We hope these checks will serve you as well as they have served Okta. At the end of the day, this is a ‘least privilege’ issue. 

The Five Additional Checks

Okta API tokens must be configured with Network Zones to restrict authorization from known networks. API tokens are almost always privileged and sensitive. 

This check helps to verify that for all Okta-specific API tokens, an IP restriction is in place to help confirm that if a token is compromised, it cannot be used from an unapproved IP. Typically, a customer would configure this to be either VPN/SASE IP ranges, datacenter (cloud) ranges, or known office ranges. These should be configured to known and “owned” contiguous IP space. In the case of cloud, it should be a known contiguous IP range that is allocated only to your organization. Allowlisting the entire IP range of a public cloud service provider like AWS, Google or Azure would not be appropriate. 

Okta API tokens must be created under dedicated user accounts.

This is an Okta-specific check to help confirm that API tokens (NHI) are under a dedicated account that is not tied to an administrator. This aims to reduce privileges for NHIs and check if they are appropriate for their use cases. 

The Okta Global Session policy must be configured to allow or deny IP based access in accordance with the Access Control policy for Okta.

This check helps confirm that a Global Policy is defined for your users. In many companies, workforce users should only request resources from approved VPNs or SASE services (i.e. not from the general internet).  In the DoD use cases, this may be restricted to NIPRNet or other approved networks.

Okta must be configured with Network Zones defined to block anonymized proxies according to organizational defined policy.

Anonymized proxies are often a source of malicious traffic. Blocking this from the outset can help reduce probes as well as attack vectors. As a commercial customer, you may want to allow anonymized proxies for maximum reach and compatibility, but consider blocking them for privileged use cases. 

For each application integrated with Okta, network zones must be defined in its authentication policy.

This check helps to confirm that every application configured in an Okta organization takes IP restrictions into consideration. Does it really need to be accessible to any malicious actor on the internet? Customers should take a risk-based approach and work to verify that network restrictions are appropriate for the accessibility and use cases. The default is to allow internet access to the application; so, care should be taken to evaluate whether that is appropriate for the application.

Call to Action

We recommend customers assess their Okta organizations against the updated STIG. 

The Okta IDaaS STIG is available to download at https://public.cyber.mil/stigs/downloads/, search for Okta. If you have feedback on the STIG, please contact fedramp@okta.com.