When risk changes, know what needs attention next

How shared security signals could help Setu connect a new threat assessment to the identities, applications and business services that need attention.

September 5, 2026 · Product direction

Security teams should be able to use a new risk assessment from one tool to improve the decisions they make across their environment. They should see which business resources deserve attention, understand why, and know when the evidence supports lowering that priority.

That is the customer outcome behind our proposed OpenID Shared Signals Framework integration for Setu. We are designing it to connect changing risk assessments from security providers to Setu's view of identities, assets and their relationships. The first milestone is a controlled pilot that shows the effect on investigation priorities before those changes influence operational decisions.

Consider a manufacturer whose endpoint security tool raises the risk associated with an employee. The employee can reach an application used to release products for shipment. A second employee receives a similar risk assessment but has no known path to that application.

The security team needs to understand that difference. Finding it may require joining the endpoint finding with identity records, application access and the business owner's knowledge. Meanwhile, the assessment can change again as the investigation progresses.

Our goal is to make that context available with the risk change. With verified identity links and sufficient relationship data, Setu would show the affected principal, the important resources it can reach, and the evidence behind the change in priority. Missing relationships would remain visible as gaps.

Customers would gain three practical capabilities:

• Prioritize with business context. Understand why a risk change matters for a particular application or service, alongside the provider's assessment.
• Spend less time reconstructing the same story. Bring external risk context into an existing investigation, with its source and affected identity attached.
• Reassess after recovery. Remove the contribution that has been resolved while keeping unrelated compromise evidence in view.

The Zscaler–CrowdStrike partnership supports this direction. On September 2, Zscaler described a planned integration that uses OpenID SSF to carry CrowdStrike risk context into its Adaptive Access Engine. The announced use case connects a changing assessment to a changing access decision. Zscaler announcement.

CrowdStrike's June preview explains the recovery side too: its proposed flow sends risk-level changes using SSF and the Continuous Access Evaluation Profile (CAEP), allowing Zscaler to restrict access or require additional authentication, then restore access when risk falls. Both announcements describe forthcoming functionality. CrowdStrike preview.

We read this as evidence for a shared thesis: a security assessment becomes more useful when another system can use it to revise a decision. The partnership demonstrates industry investment in that approach. Setu's proposed contribution is to apply it to investigation priorities and connected business exposure across a customer's supported security tools.

Open standards provide a common way to communicate those changes. SSF defines the exchange framework; CAEP includes risk, session and device-related events. They give cooperating systems a shared vocabulary while leaving each receiver responsible for how it interprets the evidence. OpenID specifications.

That interpretation matters to customers. A password change might be routine maintenance. A revoked session might be a successful containment step. A HIGH assessment from one provider might remain relevant after another provider reports LOW. Each needs its source, scope and history preserved.

Setu's design therefore keeps external assessments attributable. A repeated notification would not count as another incident. A recovery event would clear only the contribution it addresses. If a source stops reporting, Setu would show uncertainty rather than assume the threat has disappeared.

Return to the manufacturer. During the investigation, the analyst should be able to explain why the affected employee's access to the shipment application deserves attention. After remediation, the same view should explain which evidence has cleared and what still needs investigation. The customer benefit is a priority that follows the available evidence throughout the incident.

We plan to begin with a qualified transmitter, a defined customer cohort and shadow evaluation. The pilot will compare investigation priorities with and without the shared signals, examine false escalations, and test recovery. Live access enforcement would require a separate policy decision and validation. Provider compatibility and measured benefits will depend on those results.

The outcome we intend to earn is concrete: when a security tool learns something new, the team can see what it means for the business, decide what needs attention, and revisit that decision when the evidence changes.