The negative effects of checking for user credentials at the beginning of a session and granting hours-long access have surfaced many issues, sometimes leading to major security incidents, for users and organizations alike. Continuously checking is an option but not all checks are created equally. Let’s look continuous authentication and continuous authorization to see which is nice to have and which is mandatory.

Continuous authentication (AuthN) may mean different things based on how an application or resource is deployed. An authentication chain may require the user to authenticate at each step. The user is asked for credentials when they log into the VPN, then when they access the internal web application, and then again when the internal web application tries to access an internal database with RBAC (Role-Based Access Control) configured. This doesn’t sound fun for the user and certainly doesn’t boost productivity. Continuous AuthN may also mean that the user is prompted for credentials during the session, either at timed intervals or when a change triggers an authentication request. This may be when a user is at home and then goes to the coffee shop. The user session may have been suspended, but a new authentication request will allow the session to resume. Moreover, a combination of authentication methods such as MFA (multi-factor authentication) including certificate-based authentication may be used for the continuous authN to make it less intrusive.

In the above examples, the user is being verified, however, there is no indication as to what happens to the rights and privileges of the user during the life of the session. Continuous authorization (AuthZ) may be much more useful in these scenarios, and when done right (instantly) is mandatory for adherence to Zero Trust principles.

Continuous AuthZ may happen at any time during the session and may be triggered in various ways. Updating user and device authorization could result in more access, less access, or no access at all. Let’s look at some real-world examples of how continuous AuthZ can be used:

  • A user employed at a bank in Canada is out of the country and can’t access high-risk applications. However, when they deplane in Canada and open their laptop at the airport lounge, they automatically get more access since the country code is reported back.
  • A user working on a medium-risk application has been using her work computer to run application for her 3D printer. The latest version of the application has been tampered with and the EDR is detecting malware. Through the EDR integration, authorization is updated on the fly and only low-risk, read-only access is granted.
  • A user has his own device, with full admin privileges, and decides to disable personal firewall and auto updates which are both mandatory for access per corporate security and access policies. The user, working in an authentication session, now loses all authorized access. The user is notified why and is able to fix the issue by re-enabling the required parameters or allow for auto-remediation.

In all of these examples, the user does not need to log in again or do anything to see changes in authorization. The change in authorization happens immediately relative to policy requirements which consistently and continuously protects the organization. It is worth noting that other vendors are purely focused on continuous authentication while others think “continuous” authorization checks that happen every 15 minutes are acceptable.

To learn about more about to enable continuous authorization without compromising privacy, check out