Contents

Changelog

Device Auth: Introducing Notify Only Check Strategy

Fritz Ifert-Miller
February 8th, 2024

Note: Notify Only is a feature only available for organizations using our Device Trust for Okta solution.

Blocking devices from authenticating can feel intimidating, whether you’re rolling out Kolide’s Device Trust capability for the first time, or just enabling a new Check. Now, rather than jumping right into the deep-end, you can dip your toes into the water of device trust and more gently roll out Checks with our new remediation strategy: Notify Only.

Notify Only gives users a chance to familiarize themselves with both Kolide and self-remediation, without being blocked from authenticating. When a Check fails, users will receive desktop notifications via the Kolide menubar app. They will also be informed of the failing Check when attempting to authenticate, but have the option to bypass the screen and continue logging in. You can think of Notify Only as a sort of authentication speed bump.

In addition to this new Notify Only remediation strategy, we have simplified the process of configuring a remediation strategy for Checks. We have added the ability to delay the onset of Check failure notifications so that users can avoid being immediately pestered for issues which may self-resolve on their own, given time.

Let’s dive in and examine how these improvements can help you roll out Kolide’s device trust capabilities faster and more confidently.

Configuring a Check To Notify Only

With the addition of Notify Only we now offer 4 remediation strategies:

  • Do Nothing (Report Only)
  • Notify Only
  • Warn Then Block
  • Block Immediately

To enable the Notify Only remediation strategy, you will go to a Check’s configuration sidebar and select Notify Only in the Remediation Strategy section:

Kolide offers four different remediation strategies that can be chosen from the Check’s configuration sidebar.

A configurable delay interval can be set to defer the start of the Check notifying users. You may wish to use this for Checks you anticipate self-resolving given adequate time (eg. An automatic update being applied to a browser or an operating system), to avoid unnecessarily pestering a user.

When a Check fails and is configured to Notify Only it will:

  1. Generate an issue for the failing Check
  2. If a notification deferral interval is set, it will wait for that time period to elapse
  3. Notify users via desktop notifications and through the Kolide menubar app icon
  4. Interrupt the authentication flow during sign-in to Kolide protected apps with the same screen that would be seen if the Check was configured as blocking

An Authentication Speed Bump

When a user is failing a Notify Only Check and attempts to authenticate into a Kolide protected application, they will encounter a screen similar to the one seen for a blocking Check.

When using “Notify Only,” users are always able to bypass notifications when they sign in to apps protected by Kolide Device Trust.

Unlike the blocking variant of this screen, a Check in Notify Only mode will always allow the user to continue signing in, bypassing the warning. This feature can be used to test new Custom Checks, minimize the disruption of Checks that would otherwise instantly block large numbers of users, or to get organizational buy-in to Kolide during implementation.

A New State for the Kolide Desktop App

We have added a new Notify Only display for the Kolide icon of the Kolide menubar app. Now, when a device is failing a Notify Only Check the Kolide icon will have a blue notification dot instead of a yellow warning triangle.

The Kolide Menu Bar App will display a blue dot when the device fails a Check that’s “Notify Only.”

Similarly, desktop notifications will be sent with a blue-circle emoji at the start, indicating that Check is not blocking and is set to Notify Only.

Warn Then Block Checks Get a Little Friendlier

In the past, a Check that was configured to Warn and then Block would begin warning users immediately after they failed a Check. We’ve added the ability to delay the start of that initial warning period. Now, once a “Warn Then Block” Check fails, you can control when a user will first be warned and after how long they will subsequently be blocked.

A delay for both the onset of warning, and the onset of blocking can now be independently configured for Blocking Checks

This pre-warning grace period will allow you to maintain the blocking status of important Checks without bothering your users for things that just need a little bit of time. For instance, Google Chrome releases frequent updates, but these will often install automatically in the course of normal usage.

The ability to delay the start of Check notifications was one of our most requested product features and we feel it will dramatically improve the experience not just for your end-users, but also for administrators who should have to field fewer support tickets and complaints.

Share this story:

More articles you
might enjoy:

Changelog
Device Auth: Snooze and User Experience Improvements
Caitlin Cabrera
Changelog
Streamlining Authentication: Actionable Notifications on Mobile
Jonathan Nogueira
Customers
How Clio Practices Security With a Culture of Trust
Kolide
Watch a Demo
Watch a Demo