More Slack App Improvements and Settings

As a follow-up to our grace period announcement yesterday, we are excited to share more big improvements to the Kolide Slack app.

Failure Summary Options

Kolide only sends a failure summary to end-users when their devices are failing checks and only once every weekday to help reduce alert fatigue.

Sometimes though, getting a message every weekday can feel a bit much. Starting today, Kolide admins can pick the days of the week to send these messages. Whether it's reducing to just three days a week or implementing your very own #kolidefixfriday, we hope the additional flexibility helps you tune the right notification frequency for your company.

Additionally, it can be quite fatiguing to receive a notification for a device that has been sitting in a drawer for a few weeks. To help with that, we've introduced a new option that allows you to only notify users when the device has been seen recently.  We've found this so helpful in practice that we set the default threshold to 7 days or less, but you can choose whatever makes sense for your team.


While end-users won't receive a proactive notification for an offline device, they can still see them in their Kolide app home tab after clicking the Show Offline Devices button.

Escalation Options

In addition to the improvements above, we've shipped new settings options to configure failure escalations

Previously, when you set up the Kolide Slack app, admins could choose only one channel for all failure notifications, automatic escalations, and end-user help requests. With today's release, admins can now choose different channels for all three use cases, including directing user help requests to a dedicated channel where IT staff can more easily see them.

On top of that, we now offer greater customization of the Contact Admin for Help button in Kolide's Slack message. Admins can customize the reply we send users when this button is pressed, allowing for internal guidance — like how to submit an IT ticket. Messages can even include dynamic information from the notifications the end-user escalated!

We hope these help you better customize the Slack app experience for your end-users. Please let us know what you think!

New: Slack Notification Grace Period

Today, when a device fails a Check, Kolide immediately schedules a Slack message to be sent to an end-user during their next notification window (the next weekday afternoon in their local time).

For many Checks, this is desired; Kolide has caught a serious problem, and you want to let the user know about it quickly. Sometimes though, this approach can feel a bit punitive. For example, if Kolide detects a Windows device is missing an important update that was just released, you may want to give the user at least a few days to take care of the problem before triggering a reminder.

To help with this use case, we are excited to introduce a new feature called Notification Grace Periods. When a grace period is configured for a Check, Kolide will generate a failure as soon as it detects a problem but will hold the notification sent to the end-user until the grace period has expired. 

To configure a grace period, go to the Check's configuration page and ensure the Notify Device Owner strategy is selected. If it is, a new dropdown will appear where you can choose how many days you'd like Kolide to wait before notifying the end-user. When the grace period expires, we will notify them during their next notification window.

We highly recommend choosing a delay on any checks where the user's failing state is temporary and will likely be resolved by the end-user within a few days. The Windows and macOS missing important update Checks are great candidates for this new feature.

To help admins better understand the state of a Failure with a grace period, we updated the failure details sidebar to show when the end-user was first notified and when Kolide first detected it. We've also added the first notified time to the table view and the failures API as first_notified_owner_at

While we do not proactively notify end-users about failures in the grace period, we still allow motivated users to see these failures if they wish when interacting with the Kolide Slack app. If a user has failures that meet this requirement, they will see an option to view those failures in their Slack app home tab, or when they type the status command.

We hope you find this new feature useful. As always, we welcome your questions and comments.

Customize the Privacy Center

We hope you are enjoying your summer (or winter for our friends in the Southern Hemisphere). We've been working hard on our end on a slew of changes to Kolide's Privacy Center. These new features are now available and can be found in the new Privacy Center Configuration screen

You can now limit who can sign into the Privacy Center (great when you are in the process of rolling out Kolide) and can control which authentication methods are shown to end-users when they are prompted to sign in. These new options join the major changes we made to the sign-in process we announced earlier this year.

With that said, perhaps my favorite feature is the ability to customize the content within the Privacy Center.

Add a Custom Section to the Privacy Center

Many of our customers have embraced the Privacy Center, which has quickly become the home base for end-users to learn about the company's endpoint security strategy. 

Over time we've gotten many requests to customize the content to include important company information relevant to their end-users. 

Starting today, Kolide administrators can create a custom section with any information they'd like. Text, links, and any other markdown formatted content can be displayed at the top of the Privacy Center for all end-users.

You can find these customization options in the new Privacy Center configuration screen under settings.

We hope everyone takes advantage of the Privacy Center customization to improve their end-users understanding of Kolide and point them to important security and IT resources. 

Kolide Side Dishes

At Kolide, we typically ship changes and improvements to the product multiple times a day. The vast majority of these changes are modest improvements not worthy of their own change-log post, but together, they can make a big difference. We call these smaller features side dishes!

In this edition of side dishes, we have four exciting features to announce!

Improved Privacy Center Sign-In Experience

Over the last several months, we have invested a lot of energy into Kolide's Privacy Center, including letting users see the full set of device properties, checks, and other queries run on their device. While these improvements are great, end-users can't realize their benefits if they need to spend time fighting with a sign-in screen instead of reading the content. 

We've updated our Slack application to give end-users buttons instead of links to the Privacy Center to make things a lot easier. Unlike the normal Privacy Center links (which will lead most end-users to a sign-in screen), these buttons will actually open the browser using a secret and personalized URL that will automatically sign them in. 

Additionally, we've made some improvements to the privacy command to give end-users more information about their data before sending them to the Privacy Center. You can see an example below:

We've built this with security in mind. For example, Kolide administrators who sign in to the Privacy Center using one of these magic buttons will still need to authenticate fully when they try to access any sensitive functionality.

New Automatic Device Deletion Settings

As our customers continue to grow the number of devices they enroll, many of them are looking for more advanced options to manage when inactive devices are removed automatically or if multiple device records exist in Kolide for a device with the same serial number.

With our new Automatic Device Deletion setting screen, you can tune the behavior of those options to your liking. If you find yourself frustrated by seeing too many retired devices, or old instances of devices that have to be re-provisioned to new users, I highly recommend checking out these new settings.

Renamed Device Privacy to Restrictions

Our Device Privacy settings page has been renamed to Restrictions to reflect the options available on that screen better. Here you will continue to find settings that allow you to turn off features, restrict Osquery tables, and restrict the visibility of data collected about devices.

Kolide MDM Column 

For those taking advantage of our MDM capabilities, we've added a new column in Inventory called "Kolide MDM." This will enable sorting and filtering by the managed state of the device.

Additionally the attribute kolide_mdm was added to the Device API response

Introducing Live Refresh

At Kolide, we do our best to strike a healthy balance between the performance impact of our agent and the usefulness of the data we collect in the UI. In practice, this means we optimize every query to minimize impact and run expensive queries as infrequently as necessary. 

Sometimes though, when actively viewing a device, you may want the most recent information possible. To assist with this use case, we are rolling out a new feature called Live Refresh. Here it is in action!

Data Last Retrieved Timestamps

Being able to refresh data live starts with understanding when the data you are currently looking at was collected. To help with this, we have updated all of our widgets and device property tables to show the last time the information was retrieved from a device.

In some cases, like the Security Features widget shown above, many queries contribute to this display; when this happens, Kolide shows the retrieved date of the oldest data in the widget.

Kicking Off a Live Refresh

Kicking off a Live Refresh is as easy as clicking the Refresh Data button on any applicable device widget or device property screen. The necessary queries needed to populate the widget's display will be immediately issued to the device. If the device is online, the refresh should return in 10 to 15 seconds. You can also kick off refreshes for offline devices. Then, when they come online, they will refresh their data ASAP.

Once a refresh is done, the widget or table will change colors, letting you know the new data is ready to be reloaded. Simply click the "reload data" button, and the new data will load right into the UI.

While the feature is extremely straightforward, building it was no small task. In fact, a lot of it relied on the work we did to ship our data device collection control capabilities earlier this year. I want to thank the entire engineering team at Kolide for their hard work in making this feature happen. I want to also thank our customers for all of their input, leading to this feature being fully realized. We look forward to your feedback!

New Slack Option - Skip Personal Device Enrollment

A few weeks ago, we introduced a new dedicated options screen for managing the behavior of Kolide's Slack App. This week, we added a new option to this screen for organizations that do not want their end-users to enroll their personal devices into Kolide.


Previously, when any user self-enrolled a device, Kolide's Slack app would ask if it was a personal or organization-owned device. However, some organizations may not want to allow end-users to enroll their personal devices. 

If this sounds like you, change the setting to Allow ONLY organization-owned devices to enroll in Kolide. Once saved, this part of the enrollment process will be skipped, and every newly enrolled device will be marked as organization-owned.

Please Note: This setting does not convert previously enrolled personal devices into organization-owned ones. To convert them, you will need to simply remove/delete those devices from Kolide and have the user re-enroll them with the new correct choice.

API - New Global Failures Endpoints

In March, we introduced a new global failures view to Kolide. This view makes it much easier for administrators to locate failures without clicking into a specific Check. 

Since releasing this feature, we've heard a lot of great feedback from our customers that would love to list failures without needing to know anything about a check beforehand. Well, we've heard you, and we are proud to announce that we've just shipped an update to our API that enables just this use-case. So let's run through the changes.

New Failures Endpoints

View the documentation about this endpoint.

The new failures endpoints make it simple to list and access specific failures without knowing anything about the check or device they belong to. Here are some things you can do today.

List All Failures

https://k2.kolide.com/api/v0/failures

This endpoint lists all failures for all enabled checks, regardless of their resolved/open/ignored state. Once you have an API token, you can call it using the following curl example:

curl -H "Authorization: Bearer $PRODAPIKEY" 'https://k2.kolide.com/api/v0/failures'

List Failures By Status

Failures can be ignored, resolved, or open. Accordingly, you can scope the list of failures using those keywords as shown below:

https://k2.kolide.com/api/v0/failures/open
https://k2.kolide.com/api/v0/failures/resolved
https://k2.kolide.com/api/v0/failures/ignored

curl -H "Authorization: Bearer $PRODAPIKEY" 'https://k2.kolide.com/api/v0/failures/open'

curl -H "Authorization: Bearer $PRODAPIKEY" 'https://k2.kolide.com/api/v0/failures/resolved' 

curl -H "Authorization: Bearer $PRODAPIKEY" 'https://k2.kolide.com/api/v0/failures/ignored' 

All of these endpoints respond with a structure that matches the https://k2.kolide.com/api/v0/devices/<deviceID>/failures https://k2.kolide.com/api/v0/checks/<checkID>/failures endpoints.

Show A Specific Failure

Before, admins could only retrieve details for a single failure through the device or check API endpoints. Now, if you know the failure's ID, you can use just the following endpoint:

curl -H "Authorization: Bearer $PRODAPIKEY" 'https://k2.kolide.com/api/v0/failures/$FAILUREID'

New Failure Attribute - escalation_status

In addition, we've added a new attribute to the failure entity to indicate the escalation status of the failure. The escalation_status attribute can have one of the following values:

  • Not Escalated
  • User contact attempts exhausted
  • User requested help
  • No owner assigned

You can get more information, including full response schemas, on our API documentation site.


As always, we welcome comments and feedback from our API users. If you have a use case, please reach out to us via support@kolide.co or Intercom, and we'd love to chat about it.

New Inventory: Mac Startup Configuration

Have you ever wondered if a Mac had an EFI firmware password set or if Secure Boot has been turned off? Well, instead of wondering, you can now instantly look up the state of these options and other boot settings in our newly released device property in Inventory called Mac Startup Configuration.

The settings reported in the device property can help administrators better understand the security posture of a Mac. For example, a Mac with Secure Boot off may be at greater risk of being infected by malware that changes the master boot record (MBR). Additionally, the presence of a firmware password could prevent an administrator from reprovisioning a device to a new employee if they forget to turn it off before shipping the Mac back to HQ.

New Inventory Widget

To help you interpret these startup options, we have created a new widget that summarizes them with icons and easy-to-read statuses.

Privacy Center & Data Collection

Like all of our device properties, we have documented the purpose,  privacy information, and the example data set a Mac will return in the Privacy Center.

If you don't want to collect this data from your Mac fleet, you can also take advantage of our new data collection opt-out feature.

A Note About Older Macs or Macs with Apple Silicon

Macs running Apple Silicon instead of an Intel processor do not support several of these startup options. These options include Firmware options and the ability to boot Windows. For these devices and older Intel Macs without a T2 series chip, you'll see the value "Not Applicable" for any relevant settings.

As always, please let us know if you have any questions, suggestions, or improvements we can make. We hope you get value out of the additional visibility.

New Slack App Access Control Setting

Kolide's Slack app enables end-users to identify and self-resolve important issues on their device. Our Slack app has always been a major part of our Honest Security strategy, so it's important we break down as many barriers as possible to enable every single one of our customers to use it.

To that end, we are excited to be rolling out new access control settings for the Slack app. These settings are perfect for organizations that have widely rolled out the Kolide agent but haven't taken the plunge with the Slack app. Many may want to test the self-remediation workflow with just a handful of users before rolling it out widely.

To support this use case, we just launched a new settings page available to administrators that will control precisely who can and cannot interact with the Slack app.

Notice the section labeled, "Who Can Communicate With the Kolide Slack App." If you choose the option "Only users who have who have been explicitly Onboarded," then anyone who hasn't been explicitly invited to use the app in the onboarding manager will not receive any messages from the Slack app. If these same users try to initiate an interaction with the Slack app, they will be greeted with a message that looks like this...


We've also updated the onboarding manager to make the onboarding status for each user much clearer and highlight important settings that impact the Slack experience front and center.


This new setting truly turns off all possible Slack notifications, even notifications that an administrator may directly initiate. So, for example, if you decide to restrict the Slack app to just onboarded users and then try to ping them manually, you will instead see a gentle reminder to onboard them first. This is true even for sensitive device notifications.

We still recommend the original behavior, but we hope this additional setting can help many organizations test out the Slack application in a controlled manner before committing to a company-wide roll-out.

As always, we welcome your questions, comments, and feedback.

Privacy Center - Detailed Checks and More!

A few weeks ago, we announced a major set of improvements to our Privacy Center. These changes give end-users an unprecedented level of transparency into what data is collected from their devices so they can feel confident in enrolling in Kolide, an important principle in Honest Security.

After launching these improvements, we received a ton of positive feedback and some great suggestions we could implement to improve it further. To that end, I am excited to announce two major improvements that we've just shipped.

Detailed Checks

The biggest part of this update is a major improvement to the Checks section of the Privacy Center. Before this update, Checks were simply listed with a hover tooltip of the description. While this was a great start, the list wasn't very user-friendly, nor did it provide end-users with enough information to understand the purpose of each Check or what data was sent to Kolide from their devices.

This new experience is much better.

First, we organized related Checks together into lists and added rich icons, making them much easier to browse.

Second, we added write-ups for each Check that include the query that runs on the device, the purpose of the Check, and even privacy information when applicable. Here is an example of the Check named "1Password - Disallow Plain Text Emergency Kit".

Finally, we've also updated the CSV export to include the description, privacy information, and Checklist name.

View Only Relevant Information For Your Devices

The primary goal of the Privacy Center is to ensure users can understand what data will be collected about their device before they enroll. Once a device is enrolled, however, an end-user may want to transition to an experience where they only see information about Checks and other queries that run on their device.

To help, we've added a filter at the top of the page that will automatically hide any device properties, Checks, and scheduled queries that are not run on their currently enrolled device(s).


This filter is also available when drilling into a Checklist that contains many Checks, as shown below.


We are so excited to see these changes in action and cannot wait to hear more feedback from you. We have many exciting changes for Checks planned this month, and our updated Privacy Center lays a great foundation for their arrival.

As always, please do not hesitate to reach out with questions. 

Show Previous EntriesShow Previous Entries