>_this article is based on the okta SSO and adaptive MFA License

Authentication policies in Okta provide a flexible and powerful way to control how users access applications and services. By defining specific conditions—such as user group membership, device trust level, location, or network—administrators can enforce tailored authentication requirements like multifactor authentication (MFA) or passwordless sign-ins. These policies help organizations enhance security, meet compliance standards, and improve user experience by applying the right level of protection to the right access scenarios.

Authentication policies are simple yet powerful.
Each policy contains a set of rules that can be used to enforce conditional access. These rules are evaluated in a specific order, giving administrators control over which context (such as device, location, or user group) should be verified at each step of the authentication process.

Default Policies in Okta

A Starting Point, Not the Finish Line.

With every Okta tenant running the Identity Engine, a default policy called “Any two factors” is provided. While this policy is useful for initial setup and testing, it is not recommended for long-term use in production environments.

Pros:

• Available by default
• Provides basic multifactor authentication (MFA) requirements for all new apps

Cons:

• No adaptive MFA capabilities – it does not evaluate context such as device state, location, or risk signals
• Not phishing-resistant if users are allowed to authenticate with weak factors other than FastPass or FIDO2

Recommendation:

To improve security and user experience, consider replacing the default policy with custom authentication policies that:

• Leverage contextual signals (device trust, geolocation, IP reputation)
• Require phishing-resistant methods like Okta FastPass, FIDO2 keys, or biometrics
• Define app-specific rules for higher-risk applications

So, it is great to have that policy but it is recommend to have a own policy set in place to protect the ressources.

From Name to Strategy: Structuring Your Policies

You wouldn’t teach a newborn to walk before giving them a name — and the same goes for your policies. A clear naming convention is the first step toward a secure and scalable identity strategy.

• By adding numbers to the beginning of your policy names, you can easily sort and manage them in a logical order.

• The naming convention used in the displayed Okta authentication policies appears to follow a functional and descriptive approach.

1. Target-Based Names (in my case starting by 1=dashboard/entry,2=enduser,3=admin apps)

Whether targeting end users, admins, or specific Okta features like the dashboard or browser plugin, this naming convention helps ensure clarity in policy assignment and access control logic. These include names that clearly indicate the scope or audience of the policy like:

• Okta Dashboard & Browser Plugin
• Okta End User Settings
• Okta Admin Applications

Device Management or Platform-Based Policies (in my case starting by 4)

These policies are tailored to specific device platforms or management solutions, such as Jamf or Intune. They enforce authentication requirements based on how the device is managed, the operating system in use, or the tool integrating with Okta. This allows for precise control over desktop access and ensures that security posture aligns with the organization’s device trust and compliance standards.

Risk/Access-Based Levels (in my case starting by 5,6,7,8)

This policy structure classifies applications based on their sensitivity and business impact. Each level — from Low to Critical — defines specific authentication requirements appropriate to the risk posed by the application. This approach ensures stronger protection for high-value resources, while maintaining usability for lower-risk services. It supports scalable and context-aware security across the organization.

Application-Specific Naming (in my case starting by 9)

These include names that clearly indicate the scope or audience of the policy:

• Microsoft Office 365
• Google Workspace
• Slack etc.

Authenticators [belonging]

An authenticator is a method used to verify a user’s identity during login or when accessing protected resources. It forms the core of multifactor authentication (MFA) by requiring something the user knows, has, or is.

In Okta, authenticators can be configured based on the level of trust required, the device context, or the sensitivity of the application. Okta supports a wide range of authenticators, from modern, phishing-resistant methods like FastPass and FIDO2, to legacy options like SMS or voice calls (not recommended for secure environments).

✅ Recommended (Phishing-Resistant / Modern)

FastPass (Okta)
Passwordless, phishing-resistant authentication using device trust and biometrics. Works seamlessly on managed devices and integrates well with device assurance policies.

FIDO2/WebAuthn (e.g., security keys, biometric platform authenticators)
Strongest form of MFA. Based on public-key cryptography. Resistant to phishing, replay attacks, and man-in-the-middle attempts. Recommended for high-risk or critical applications.

Authenticator	Description	Phishing-Resistant	Device Awareness	Use Case
FastPass	Okta’s passwordless solution using device trust, biometrics, and platform checks	✅ Yes	✅ Yes	Best for managed devices, SSO
FIDO2 / WebAuthn	Security keys (e.g., YubiKey), platform authenticators (Windows Hello, Touch ID)	✅ Yes	✅ Yes	Critical apps, admins, high security

More: https://iamse.blog/2023/02/07/phishing-resistant-authenticators-in-action-through-okta-fastpass/

⚠️ Conditionally Acceptable (Not Phishing-Resistant, Still Strong)

One-Time Passwords (OTP via Password or App)

• Not tied to device security posture
• Better than SMS, but still phishable
• Can be stolen via social engineering or malware

Authenticator	Description	Phishing-Resistant	Device Awareness	Use Case
TOTP (Time-based OTP)	App-based OTP (e.g., Google Authenticator, Okta Verify)	❌ No	❌ No	Medium-trust apps, fallback MFA
Push Notification (Okta Verify)	Push to Okta Verify app for approval	❌ No	✅ Partial*	Balanced UX/security, default MFA

❌ Not Recommended (Weak / Legacy / Phishable)

SMS (Text Message)

• Vulnerable to SIM swapping, interception, and social engineering
• Not phishing-resistant
• Often used as a fallback — but should be avoided for critical access

Phone Calls

• Susceptible to interception or voicemail takeover
• Easily tricked by attackers through spoofing
• Slower and less user-friendly

Authenticator	Description	Phishing-Resistant	Device Awareness	Use Case
SMS	OTP sent via text message	❌ No	❌ No	Only for fallback — not secure
Voice Call	OTP delivered via phone call	❌ No	❌ No	Highly vulnerable — avoid
Email Magic Link / OTP	Link or OTP sent via email for login	❌ No	❌ No	Convenience use only, not secure
Password	Basic authentication, legacy method	❌ No	❌ No	Should never be standalone

Authentification Context

Management status (managed vs. registered vs anything else…) [belonging]

A device in Okta can be in one of three states.

• registered: A device becomes registered when Okta Verify is set up with the user account. Registration allows the device to be recognized by Okta but doesn’t guarantee device management or full trust.
• managed: A device is managed when, in addition to registration, it meets further conditions — such as receiving a certificate or being enrolled via MDM (Mobile Device Management). Upon successful verification during the next login, Okta marks the device as “managed.”
• Any = Neither (unregistered and unmanaged) In policy conditions, “Any” refers to devices that are neither registered nor managed — typically BYOD or untrusted endpoints. These are often treated with the highest caution or been blocked.

https://help.okta.com/oie/en-us/content/topics/identity-engine/devices/managed-main.htm

Device Assurance (Desired state enforcement) [belonging]

Device Assurance Policies define the minimum platform and security standards a device must meet in order to access resources protected by a authentification policy. These standards ensure that only devices in a secure and compliant state are granted access — based on OS version, encryption, biometric setup, and more.

Policies are platform-specific (Android, iOS, macOS, Windows) and can be tailored by security level, such as:

Default Policies

Default-level policies enforce a baseline level of security. These are typically used for non-sensitive or moderately sensitive access, such as apps with an Access Level of Low or Medium.
Examples of requirements may include:

• Device not jailbroken/rooted
• Passcode or biometrics enabled
• Disk encryption active
• OS version meets minimum standard

These settings aim to provide reasonable protection without heavily restricting user access or excluding personal (BYOD) devices.

Critical Policies

Critical-level policies are applied to Access Level – Critical apps and are designed for maximum security assurance. These policies are typically used for administrative tools, identity providers, or systems with sensitive financial or customer data.

Additional or stricter conditions often include:

• Support for hardware-backed security (e.g., TPM, Secure Enclave, hardware-backed keys)
• Mandatory biometric auth (e.g., Windows Hello, Face ID/Touch ID)
• More recent OS versions
• Disallowed legacy platforms (e.g., Windows 10)

By applying critical assurance policies, organizations can ensure that only the most secure, fully compliant devices are allowed to access mission-critical resources.

https://help.okta.com/oie/en-us/content/topics/identity-engine/devices/device-assurance.htm

Zones [belonging]

In Okta, a zone is a logical group of network locations (e.g., IP ranges, countries, or geographies) used to apply context-aware policies. Zones allow you to control when, where, and how users can access applications or services by factoring in the source of the login request.

Zones are primarily used in authentication policies, especially in combination with conditional access rules, to enforce different levels of security depending on the user’s location.

✅ Recommended Zone Strategy (3-Zone Model)

To ensure both security and flexibility, the following zone structure is recommended:

🌍 Dynamic – Trusted

• Purpose: For countries or IP ranges considered safe or known (e.g., main office locations or countries with low fraud risk).
• Usage:
  • Applied to standard user policies
  • May allow streamlined login (e.g., FastPass only)
  • Can be exempt from stricter MFA

🚫 Enhanced Dynamic – Blocked

• Purpose: Used for global blocking, often based on known threat intelligence (e.g., traffic from high-risk or sanctioned regions).
• Usage:
  • Applied globally across all authentication policies
  • Immediate deny access behavior
  • Centralized in Enhanced Dynamic Zone Blocklist

⚠️ Dynamic – Blocked

• Purpose: For selectively blocked locations that shouldn’t have access to specific apps or roles but are not globally banned.
• Usage:
  • Applied only to certain authentication policies
  • Useful for isolating sensitive apps from less trusted areas without fully denying user access elsewhere

Combine zones with device assurance and phishing-resistant authenticators for maximum control and security. Zones can also be used in sign-on policies, MFA enrollment, and registration restrictions.

https://help.okta.com/oie/en-us/content/topics/security/network/network-zones.htm

Zero Trust

In this article, I aim to explore Okta’s authentication policies through the lens of the CISA Zero Trust Maturity Model (https://www.cisa.gov/zero-trust-maturity-model). By aligning policy design, and authenticator choices with CISA’s maturity stages, the goal is to help organizations move from basic access control toward a context-aware, adaptive, and phishing-resistant Zero Trust architecture. This deep dive is intended as both a practical guide and a strategic reference for building smarter, scalable authentication policies that support Zero Trust principles.

Identity – Optimal Alignment

Model Requirements (Optimal):

• Continuous validation and risk analysis
• Enterprise-wide identity integration
• Tailored, as-needed automated access

How the okta Policy Supports It:

• ✅ Phishing-resistant MFA (FastPass, FIDO2) ensures secure, continuous identity validation
• ✅ Policy-based access by context (device state, location, zone) enables dynamic and automated access control
• ✅ Fine-grained authentication policies allow application-specific control and identity validation per risk level (e.g., “Access Level – Critical”)
• ✅ SSO integration with app-specific policies brings centralized identity governance across the enterprise

Devices – Optimal Alignment

Model Requirements (Optimal):

• Continuous physical and virtual asset analysis
• Supply chain risk management
• Integrated threat protections
• Resource access based on real-time device risk analytics

How the okta Policy Supports It:

• ✅ Use of Device Assurance Policies enforces platform security baselines (TPM, Secure Enclave, biometrics, encryption, OS version, etc.)
• ✅ Device context is used in access decisions (e.g., “only allow FastPass on managed and secure devices”)
• ✅ Devices are continuously verified and reassessed based on their state — not just at enrollment
• ✅ Devices must be compliant to access critical systems, ensuring real-time enforcement

Networks – Advanced to Optimal Alignment

Model Requirements (Optimal):

• Distributed micro-perimeters
• Just-in-time / just-enough access
• Real-time configuration evolution based on risk
• Encrypted traffic and cryptographic key management

How the okta Policy Approach Supports It:

• ✅ Network zones (trusted, dynamic, enhanced blocklists) act as identity-aware micro-perimeters, controlling access based on location/risk
• ✅ Use of contextual access controls (device, location, user role) provides a just-enough access model
• ✅ Okta integrates with Secure Web Gateways (SWGs), ZTNA tools, or reverse proxies to enforce session-level controls on network boundaries
• ✅ Enforced conditional access based on IP intelligence or geo-location dynamically adapts the authentication policy

Applications and Workloads – Advanced to Optimal Alignment

Model Requirements (Optimal):

• Applications use continuous authorization
• Protections embedded in all workflows
• Application security integrated into SDLC

How the Policy Design Supports It:

• ✅ Application-specific policies enforce tailored authentication rules per app (e.g., Slack vs. Microsoft 365)
• ✅ Policies require continuous session validation using factors like device state or user location
• ✅ Critical apps require managed devices and phishing-resistant authentication, embedding security into the user workflow
• ✅ Okta integrates with app-layer protections like CASB, reverse proxy, and runtime access policies

Data – Advanced Alignment (Supports Optimal When Combined with Downstream Controls)

Model Requirements (Optimal):

• Context-based data access
• Dynamic encryption
• Enterprise-wide data inventory & classification

How Okta Authentication Policies Support It:

• ✅ Okta enables identity- and context-aware access to data by restricting access to data-centric apps based on user, device, and location context
• ✅ Tightly scoped access levels (e.g., “Access Level – Critical”) ensure only the right users and devices reach data-rich systems like HR platforms, CRM, or financial tools
• ✅ Integration with DLP or CASB solutions (e.g., Netskope, Microsoft Purview) allows extending Okta’s identity context into data-level policies

Conclusion

While the primary focus is on Identity and Devices, the Okta authentication policy strategy also contributes significantly to the Network, Application, and Data pillars** of the CISA Zero Trust Maturity Model. Through contextual access, device trust enforcement, zone control, and app-specific rules, organizations can move toward a fully mature Zero Trust posture — even across traditionally siloed areas.

The Authentification Policies

A policy stands, both smart and tight,
Checking context, left and right.
If no rule fits, access denied —
Layered trust, with watchful eyes.

Dashboard Policies

To avoid that users get logged out and to provide them access to less crititcal ressources in a maybe not that secure context from a byod, the dashboard policy rules could be designed less restrictive. This give the ability to provide the user sso access to the self service or support portal even if he has any issue with the sign on to other apps dur to bad context.

Authentication Flow for Okta Dashboard Access (Device and Zone-Aware)

This flowchart defines a contextual authentication strategy for accessing the Okta Dashboard, using a combination of device posture and network zones to determine the required authentication level — or to block access entirely.

Key Concepts:

• Device States:
  • Managed: Device is enrolled, secured, and compliant with assurance policies
  • Registered: Device has been verified with Okta Verify but may not be fully managed
  • Any: All other devices — typically unmanaged or BYOD
• Network Zones:
  • Trusted: Known safe networks or countries (e.g., corporate offices, approved geolocations)
  • Untrusted: Networks that are not explicitly trusted or blocked (e.g., home networks, public IPs)
  • Blocked: Countries or IP ranges defined in an Enhanced Dynamic Zone Blocklist — these result in immediate denial

While this authentication flow is primarily based on device state (managed, registered, any) and network zone trust (trusted, untrusted, blocked), it’s important to understand that context isn’t limited to static conditions.

Risk signals can also be evaluated in real time and treated as dynamic context.

In a high-risk scenario, even if a device is managed and in a trusted zone, the policy could enforce stronger requirements — such as:

• Blocking access temporarily until further verification
• Enforcing phishing-resistant MFA
• Requiring re-authentication immediately

Flow Summary:

Managed or Registered + Trusted Zone → Possession Factor

• Users on trusted networks with a managed or known device are allowed to authenticate using a possession factor (e.g., FastPass or Fido, phishing resistent)
• Streamlined experience for corporate users on safe networks
• Combined with a active global session, there is no reauthentification needed

Managed or Registered + Untrusted Zone → 2-Factor Phishing-Resistant MFA

• Access is allowed but only with phishing-resistant MFA, ensuring strong verification from public or unknown networks
• Combined with a reauthentification everytime to 12 hours could be a good hardening

Any Device + Trusted/Untrusted Zone → 2-Factor Phishing-Resistant MFA

• Any sign on must meet the highest available authentication standard to ensure Zero Trust
• Requires at least 2-factor with hardware-protected authentication
  ➜ This includes platform authenticators (e.g., Touch ID, Windows Hello) or FIDO2 security keys
  ➜ Phishing-resistant FIDO2 methods are also allowed and preferred

By requiring hardware-backed credentials, even BYOD access maintains strong assurance, especially in the absence of device posture signals.

Catch-All (Blocked Zone) → Deny

• Users from blocked countries or high-risk IP ranges are denied access outright through zone-based policy enforcement. This may also include locations that are not explicitly defined as globally blocked, allowing flexibility to permit access to less critical applications while still denying access to high-value resources.

Risk/Access-Based Policies

Access Level – Low

The “Access Level – Low” policy for example is designed for applications that do not handle sensitive data and where user convenience can be prioritized — such as holiday booking tools, event sign-ups, or general internal information portals.

This policy still follows a Zero Trust principle by not blindly trusting any device or location, but instead applies tiered authentication rules based on:

1. Device posture (managed, registered, any)
2. Network zone (trusted, untrusted)
3. Factor strength (possession factor vs. phishing-resistant MFA)

Rather than enforcing a one-size-fits-all rule, the Access Level – Low policy:

• Grants easy access (possession factor only) for trusted devices on safe networks
• Requires 2-factor phishing-resistant or hardware-protected MFA for less secure conditions
• Automatically scales access requirements based on risk context (device + network zone)
• Supports re-authentication based on session boundaries to reduce attack surface

Examples of Rules in Action:

Scenario	Authentication Requirement
Managed & Trusted Device (Corp Network)	✅ Possession Factor (e.g., FastPass or FIDO2)
Managed & Untrusted Network	✅ 2 Factors – must include phishing-resistant method
Registered Device & Trusted Zone	✅ Possession Factor
Registered Device & Untrusted Network	✅ 2 Factors – phishing-resistant
Any Device (Trusted)	✅ 2 Factors – must include hardware protection (e.g., WebAuthn/FIDO2)
Any Device (Untrusted)	❌ Access Denied (act like a catch-all policy)

Access Level – Critical: Zero Trust for High-Sensitivity Resources

The “Access Level – Critical” policy is designed to protect your most sensitive systems — such as admin consoles, identity platforms, financial systems, and high-privilege workloads. It enforces the strictest access controls in your environment, combining device assurance, phishing-resistant authentication, and zone-aware logic.

This policy ensures that only highly trusted users, on verified and compliant devices, from trusted networks can gain access — aligning fully with Zero Trust and CISA’s Optimal maturity model for identity and devices.

Concept Behind the Policy:

This policy enforces:

• Strongest assurance through phishing-resistant possession factors (e.g., FastPass, FIDO2)
• Mandatory device compliance via critical-level Device Assurance (e.g., TPM, Secure Enclave, encryption, biometrics)
• Restricted access to trusted network zones only (could be also your ZTNA Solution)
• Complete denial for all users not explicitly matching the approved criteria (Catch-all → Deny)

Rule Overview:

Condition	Policy Logic
Managed & Trusted Device	✅ Allow with phishing-resistant possession factor (FastPass or FIDO2)
Device Assurance – Critical	✅ Required (Android, iOS, macOS, Windows – critical-level settings enforced)
Untrusted Network or Device	❌ Blocked by catch-all — denied by default
Re-authentication Frequency	✅ On every session — prevents long-lived privileged access

This policy represents your last line of defense for critical access. It removes assumptions about device or network safety and requires users to prove trust continuously, not just at enrollment. This is a textbook example of Zero Trust enforcement and aligns directly with:

• CISA Zero Trust Model: Identity & Devices (Optimal)
• NIST 800-207 recommendations
• Enterprise-grade risk mitigation strategy

Access Level – Medium & High: Scalable Security Based on Application Sensitivity

The Medium and High access levels are essential to applying scalable, risk-based authentication aligned with the sensitivity of applications.

• Medium is possible used for applications with moderate sensitivity, such as user-facing portals or business tools. It allows BYOD (unmanaged) devices but restricts access to users connecting from trusted network zones. This ensures a strong level of security while maintaining user flexibility in terms of device choice.
• High is maybe applied to critical internal systems and applications dealing with sensitive data. It goes further by excluding BYOD access and only allowing managed, trusted devices from approved network locations. This level offers a much tighter security posture, suitable for high-risk environments.

Together, these levels provide a framework for context-aware authentication that scales with application importance, forming a core part of a Zero Trust strategy.

The Catch-All Rule: A Safety Net, Not a Back Door

The catch-all rule is your final line of defense — a policy that applies when no other authentication rule is matched. It ensures that access isn’t granted by accident or omission.

When implemented as “Deny All”, the catch-all rule guarantees that any undefined or unexpected access attempt is explicitly blocked, reinforcing the principle of least privilege and aligning with a Zero Trust mindset.

Recommendation:
For all application policies (except possibly the dashboard), the catch-all rule should always be set to deny. Once you’ve clearly defined all trusted access scenarios through context (device, location, identity), there’s no need to allow anything else.

This approach prevents policy misconfigurations or oversights from becoming security gaps — ensuring that only well-defined, context-aware access paths are permitted.

Conclusion: Plan, Test, and Embrace the Shift to Smarter Authentication

Building a scalable and secure authentication policy framework is more than a technical task — it’s a strategic process. Success depends on careful planning, consistent testing, and an understanding of how authentication impacts both users and security posture.

When guiding customers on the journey to a hardened Zero Trust environment, I recommend using a waved enrollment strategy. This allows you to gradually introduce stricter controls, accommodate user feedback, and validate configurations without disrupting productivity. It’s not about locking everything down at once — it’s about maturing with intent.

A major opportunity in this process is the transition to passwordless authentication. Solutions like Okta FastPass or FIDO2/WebAuthn offer significant advantages:

• 🔐 Security: Passwordless methods eliminate the risks of phishing, credential theft, and password reuse — addressing the most common attack vectors in modern breaches.
• 🙌 User Experience: Users benefit from faster, frictionless sign-ins that don’t rely on remembering or managing passwords. The result is both better productivity and fewer support tickets.

Passwordless isn’t just a trend — it’s a fundamental shift that enhances trust, simplicity, and protection in a connected world.

By combining structured policy design, context-aware access, and modern authentication methods, organizations can move from reactive security to a proactive Zero Trust architecture — one that grows with the business and adapts to new risks without sacrificing user experience.

thanks for reading

Access Certification Access Requests AD AD Agent AI Agent API Artificial Intelligence ASA auth0 AWS cic Cloud CSV Entitlement Management FAPI Fine-grained Entitlements Governance Identity Identity Governance IGA IGDM LDAP mcp server MFA model context protocol OAuth2 OIG Okta OPA OPA APIs PAM RACF Realms Risk Roles SaaS Secrets ServiceNow sftd SoD SPA SSO Tako AI Workflows Workforce