Hey friends, I want to explore the importance of secure configuration in identity and access management. Configuring security settings is not something I see as a one-time setup task; these controls are what stand between a stolen credential and access to company systems.
In this article, I’m focusing on some of the practices I consider when configuring Okta Policies and how those controls can work together to reduce the impact of common attacks such as phishing.
Understanding the Need for Secure Configuration
Imagine the only thing standing between an attacker and sensitive company data is a password.
That is the risk with poorly configured access management. If an employee is phished and gives an attacker their username and password, the strength of the controls behind that password determines what happens next.
For a simple example, imagine a company called CyberSafe Inc. An attacker pretends to be a legitimate IT service and convinces an employee to enter their credentials into a phishing page. The credentials are now compromised.
That does not have to mean the attacker gets access.
A properly configured identity layer can still require phishing-resistant authentication, a managed device, or additional application-specific conditions before access is granted.
Key Components of Secure Okta Configurations
There are several areas in Okta that I pay close attention to when thinking about access controls:
- Policies and Rules: These define who can access what, when, and under which conditions.
- Multi-Factor Authentication (MFA): MFA adds another layer beyond the password and can prevent stolen credentials from being useful on their own.
- Managed Device Policies: Requiring registered or company-managed devices can reduce the risk of unauthorized access from unknown endpoints.
- Session Management: Session controls determine how long a session stays active and when a user should be required to authenticate again.
Each control helps on its own, but the value comes from layering them together.
Best Practices in Configuring Global Session Policy
The Global Session Policy controls the session a user establishes with Okta. I think of it as the baseline layer before application-specific controls are evaluated.
The goal is to find a balance between security and a usable authentication experience.
Session Duration and Inactivity Timeouts
Session duration should reflect how people actually work while avoiding sessions that remain valid longer than necessary.
A day-long inactivity period may be a reasonable starting point in some environments, but I would not treat it as a universal recommendation. Administrative users, sensitive environments, and higher-risk sessions may warrant shorter durations or more frequent authentication.
Session Conditions
Session conditions can also reflect different levels of risk.
For example, an administrator or a user on an unmanaged device may need stronger authentication requirements than a standard employee using a managed corporate laptop.
The important part is not treating every authentication request as if it carries the same level of risk.
Implementing Robust MFA Enrollment Policies
MFA is one of the strongest controls available after a password is compromised, but not all MFA methods provide the same level of protection.
Where possible, I prefer phishing-resistant authentication such as FIDO.
Prioritizing Phishing-Resistant MFA
FIDO-compatible authenticators, including security keys and platform authenticators, can provide stronger protection against phishing than methods such as passwords, SMS codes, or simple push approvals.
For sensitive applications, I would make phishing-resistant authentication the expected path rather than an optional method used by a small group of security-conscious users.
Applications that cannot support stronger authentication may need additional controls around them to lower the risk.
Facilitating Secure and Efficient Onboarding
There is also an opportunity to improve the onboarding experience while increasing security.
For example, pre-registering YubiKeys with Okta can support passwordless onboarding where a new employee receives an authenticator that is already associated with their account.
That can reduce reliance on temporary passwords while making the first authentication experience easier for the user.
Strengthening Security with Password Policies
Password policies are still an important part of identity security, but I increasingly think the goal should be to reduce how much we depend on passwords in the first place.
If a password is the only thing protecting an account, password complexity rules have to carry too much weight.
Migrating Towards a Passwordless Future
I would prioritize stronger MFA and phishing-resistant authentication over continually increasing password complexity and rotation requirements.
The long-term goal is to make the password less important by moving toward passwordless authentication with technologies such as FIDO.
This does not mean password controls can be ignored overnight. It means the direction should be toward authentication methods that do not depend on a reusable secret that can be phished.
Granular Control with Application Access Policies
Application Access Policies provide a more granular layer of control because different applications can have different requirements.
A general internal application does not necessarily need the same access policy as a financial system or an administrative console.
Tailoring Policies for User Groups and Applications
I would start by understanding which groups actually need access to an application.
Someone in Marketing may need a different set of applications and controls than someone in IT or Finance.
Sensitive applications should have stricter requirements based on the impact of unauthorized access rather than applying the same policy to every resource.
Leveraging Context-Based Access Controls
Application policies can also consider context such as device type, location, and other signals available to Okta.
For example, a sign-in from an unmanaged device or an unusual location might trigger additional authentication or be denied entirely, depending on the sensitivity of the application.
The goal is to use context to make a better access decision without adding unnecessary friction to every normal authentication attempt.
Real-World Example: Comprehensive Security Configuration
To bring the controls together, imagine a mid-sized company called TechCorp.
An employee receives a phishing email and enters their username and password into the attacker’s site. The credential theft succeeds.
With layered controls in place, however, that does not automatically become a breach.
Impact of the Configuration
- MFA: The attacker cannot satisfy the FIDO2 authentication requirement even though they have the employee’s password.
- Context-Aware Policies: The sign-in attempt comes from an unrecognized device, which creates another reason to block or challenge the request and gives the security team useful context for investigation.
- Granular Application Policies: Even if one part of the authentication flow were compromised, sensitive applications still have their own access requirements rather than inheriting a blanket allow decision.
The Outcome
The phishing attack successfully stole a password, but the additional controls prevented that password from turning directly into broad access.
That is the value I see in layered identity controls. I do not expect any single policy to solve the problem on its own.
Regular Review and Update of Security Configurations
None of these controls should be configured once and forgotten.
Organizations change. New applications are introduced, employees change roles, new authentication methods become available, and attacker techniques continue to evolve.
A policy that made sense a year ago may no longer match the environment today.
Why Regular Reviews Matter
Regular reviews help catch gaps introduced by changes in the organization as well as changes in the threat landscape.
I would look at whether policies still match current application sensitivity, user populations, device requirements, and available authentication methods.
Tools and Strategies for Ongoing Security Management
A few things can make this easier:
- Automated Documentation: Generate or update policy documentation from the current configuration rather than relying entirely on manually maintained documents.
- Regular Audits: Review the Okta environment for stale configurations, unusual access patterns, and controls that no longer match current requirements.
- Feedback Loops: Listen to users and support teams. They are often the first to notice when a policy is too restrictive or behaves differently from what was intended.
Conclusion: Solidifying Your Security Stance
The main ideas I would take away are:
- Tailor policies to user roles and application sensitivity.
- Prefer phishing-resistant authentication such as FIDO where possible.
- Use managed-device requirements when they make sense for the resource being protected.
- Continue moving toward passwordless authentication.
- Review configurations regularly instead of treating them as permanent.
None of these controls is a silver bullet. Together, they can make a stolen password much less useful to an attacker.
In the next article in this series, I’ll explore automated policy documentation and how we can use the Okta API to make policy configurations easier to understand and maintain.
Join the Conversation
Take a look at your own Okta configuration. Are your policies still aligned with how your organization works today? Are there applications or user groups that could benefit from a more specific access policy?
I’m always interested in how other teams approach these problems and what has worked well in their environments.