After Initial Login: Periodic Authentication

Beyond the Initial Login: Periodic Authentication (Activity 1.8.2)

We’ve covered the absolute essential first step in Zero Trust: authenticating users and non-person entities at least once per session via a centralized Identity Provider (IdP) in Activity 1.8.1. Now, we take a step further in acknowledging that trust isn’t a one-time grant. While the ultimate goal in Zero Trust is continuous, risk-adaptive authentication, Zero Trust Activity 1.8.2: Periodic Authentication establishes a vital foundational layer by requiring re-authentication multiple times within a session.

At this stage, the focus is primarily on straightforward triggers like session duration and timeouts, where, after a set period, the user is prompted to re-authenticate. However, the activity can involve using other “period-based analytics,” which, at this foundational level, can be interpreted as slightly more intelligent, though still statically defined, triggers. This might include mandating re-authentication when a user attempts to access a specific, designated sensitive service or a class of data, regardless of how long the session has been active.

The key outcome for Activity 1.8.2 is clear: Authentication is implemented multiple times per session based on security attributes. Here, “security attributes” in this context largely refer to the simple passage of time or the static classification of the resource being accessed.

This activity is about building a basic rhythm of re-verification into user sessions, reducing the risk associated with long-lived, unverified access, even if the initial authentication was strong.

Solutions for Achieving Foundational Periodic Authentication

Implementing this level of periodic authentication relies heavily on the capabilities of your central Identity Provider and how applications are configured to interact with it:

IdP-Controlled Session Management: The central IdP is responsible for managing user sessions and enforcing re-authentication requirements. This involves setting policies that dictate when a user needs to re-authenticate based on session duration or inactivity.

Application-Triggered Re-authentication: Applications, especially those deemed to host more sensitive information or functions, are configured to signal to the IdP or an access gateway that re-authentication is required upon access attempt. This is a statically defined rule: “accessing this specific app requires re-auth.”

Policy Definition based on Duration and Static Resource Classification: Access policies within the IdP are defined to enforce re-authentication prompts based on:

The elapsed time since the last successful authentication.

A period of user inactivity.

The user attempting to access an application or service that is tagged as requiring periodic re-authentication.

This approach doesn’t involve complex risk scoring or behavioral analysis yet. That will come into play with 1.8.3 “Continuous Authentication Part 1”. It’s about applying blanket re-authentication rules based on time or pre-defined resource sensitivity.

Okta and Activity 1.8.2: Enabling the Foundational Periodic Check

Okta, as a central Identity Provider, is well-equipped to handle the requirements of Activity 1.8.2, providing the necessary controls for duration-based and statically triggered re-authentication. Okta allows administrators to define detailed session policies that control how long a user’s session remains valid and when they need to re-authenticate. Okta’s policy framework enables the creation of authentication policies tied to individual applications or sets of applications.

Where Okta’s Capabilities Extend Beyond This Activity’s Minimum:

It’s important to note that Okta’s capabilities extend significantly beyond the foundational requirements of Activity 1.8.2. While this activity focuses on simple duration or statically defined triggers, Okta is fully capable of performing more advanced, adaptive periodic authentication based on a wide range of dynamic security attributes and risk signals (as we’ll likely discuss in later activities like 1.8.3 Pt1). Okta can factor in real-time context like changes in location, device posture, or behavioral anomalies to trigger step-up authentication.

However, for the purposes of meeting the requirements of Activity 1.8.2 as described – focusing on duration and statically defined resource access triggers – Okta provides the necessary policy controls and enforcement points.

The Technical Buyer’s Focus:

Activity 1.8.2 is about implementing a disciplined approach to re-verifying user identity within a session. It’s a practical step that significantly enhances security by reducing the risk window of a compromised session. By leveraging a central IdP like Okta, you gain the ability to centrally define and enforce these periodic authentication rules based on session duration and access to specific applications. This avoids the inconsistency and management burden of configuring such policies within individual applications.

For technical buyers, achieving Activity 1.8.2 with Okta means implementing a layer of continuous verification using straightforward, configurable policies, setting a strong precedent for more advanced dynamic access controls in your Zero Trust journey. It’s about making authentication a regular check-up, not just a one-time entry ticket.

Pillar: User

Capability: 1.8 Continuous Authentication

Activity: 1.8.2 Periodic Authentication

Phase: Target Level

Predecessor(s): None

Successor(s):