Article Details

How to Streamline Zero Trust Using the Shared Signals Framework. Zero Trust helps organizations shrink their attack surface and respond to threats faster, but many still struggle to implement it because their security tools don't share signals reliably. 88% of organizations admit they've suffered significant challenges in trying to implement such approaches, according to Accenture. When products can't communicate, real-time access decisions break down. The Shared Signals Framework (SSF) aims to fix this with a standardized way to exchange security events. Yet adoption is uneven. For example, Kolide Device Trust doesn't currently support SSF. Scott Bean, Senior IAM and Security Engineer at MongoDB, proposed a way to solve the problem, giving teams an easy and intuitive way to operationalize SSF across their environment. In this guide, we'll share an overview of the workflow, plus step-by-step instructions for getting it up and running. The problem – IAM tools don't support SSF A core requirement of Zero Trust is continuous, reliable signals about user and device posture. But many tools don't support SSF for Continuous Access Evaluation Protocol (CAEP), making it hard to share or act on these signals. Teams often face three challenges: Without this interoperability, organizations struggle to apply consistent policies — and in cases like Kolide Device Trust, critical device events never reach systems like Okta. The solution – a SSF transmitter that turns Kolide issues into CAEP events Because SSF is built on HTTPS requests, the OpenID standard works with Tines' HTTP Action. Scott developed a new workflow integrating Kolide Device Trust with Tines, enabling it to send SSF signals to Okta. If a device is non-compliant, Kolide sends a message to the workflow via webhook. Tines enriches the signal, makes sure it can be linked to a user, builds a Security Event Token (SET), and then sends it to Okta. In this way, Tines acts as the connective tissue that makes SSF work across the distributed IT environment, even if individual tools don't natively support the standard. Tines can: All of which makes Zero Trust enforcement faster, more reliable, and much easier to operationalize. IT teams are empowered with continuous, real-time risk assessment of devices, faster response to threats, and more flexible policy orchestration. And end users get the benefit of automated remediation, which helps to optimize productivity and minimize IT intervention. If you want to go deeper into identity modernization, the Tines IAM guide explores how teams are unifying device trust, access decisions, and least-privilege enforcement with automation. Scott's workflow is one of several real-world patterns inside. Workflow overview Required tools: Required credentials: Required resources: Okta domain, such as example.okta.com, example.oktapreview.com, or a branded domain. How it works: The workflow creates a proof-of-concept SSF transmitter that can be registered with Okta and sends device compliance change CAEP events (sent as SETs), based on issues generated in Kolide. There are three elements: 1. Generate and store SET signing keys (SETs are signed JSON Web Tokens): 2. Expose SSF transmitter API SSF receivers (like Okta) need: Once this is live, teams can register a new SSF receiver in Okta under: And create a new stream using the API's URL and the new `.well-known` endpoint 3. Create, sign and send of SETs from Kolide events This delivers real-time device-compliance updates to Okta so access policies can respond immediately. Configuring the workflow — a step-by-step guide You can build and run this entire workflow using Tines Community Edition. 1. Log into Tines or create a new account. 2. Navigate to the pre-built workflow in the library. Select import. This should take you straight to your new pre-built workflow. 3. Gather the required credentials These ensure authenticated calls to Kolide and secure webhook validation. 4. Collect your required resources You'll need an Okta tenant domain, such as: This domain is used when sending signed SETs to Okta's security-events endpoint. Note: In the example provided, Scott set up as a `push` rather than a `poll` provider as tokens are sent based off of inbound webhooks, so there's no need to store state. 5. Generate your SET signing keys This is required before Okta will accept and verify your SETs. 6. Publish the SSF transmitter API The SSF API webhook contains two branches: Once live, Okta can register this transmitter as a shared signals sender. 7. Connect Kolide and process device issues The Kolide integration flow follows these steps: Depending on whether the issue is new or resolved: As soon as Okta receives and verifies the SET, the associated user risk level updates. Bringing it all together SSF exists to help security tools speak the same language, delivering continuous insight into risk and device posture. But when key tools don't support the standard, gaps open up, and access policies lag behind real-world changes. Tines bridges these gaps by enabling new intelligent workflows. They ensure that even tools that don't support SSF can send information in the same standardized way. By using Tines to generate, sign, and deliver compliance signals in real time, you get the benefits of SSF even when the source tool wasn't built for it. If you'd like to try this workflow yourself, you can spin it up in minutes with a free Tines account. And if you want to see how device posture fits into a broader identity strategy, this guide to modern IAM workflows offers practical patterns and real-world workflows like Scott's you can start building on today.