All release notes
Platform
The automation engine, cross-client campaigns, and evidence on every compliance check
Detect, decide, act and prove existed as four disconnected stages with a human walking between every one. The automation engine connects them, on the principle that a rule may do nothing until somebody deliberately allows it to: every rule is born report-only and records what it would have done. Alongside it, a confirmed detection at one client becomes a campaign that protects the other clients in the same partner scope before they are hit, and compliance checks now carry the measured value as evidence instead of only a verdict.
New
- The automation engine, in four tiers: rules live on the Automation page and connect an event to conditions and actions. Every rule starts report-only and stays there until a platform administrator promotes it. An execution row is written on every evaluation, matched or not, so an automation that stopped working can never look like one with nothing to do. Conditions reuse the check engine's evaluator: there is one condition language in the product, not two. A two-level kill switch, per client and platform-wide, is read straight from the database and re-checked between claiming an action and performing it.
- Actions that cannot cause harm are available immediately: notify, create a ticket, assign, add a note and tag. A tag is resolved by name inside the entity's own client and created there if needed, so a tag from one client cannot structurally end up attached to another client's records.
- Actions that change the state of the work, such as opening an investigation, setting severity, approving a patch and scheduling a patch, each sit behind an explicit per-rule opt-in. Flipping that opt-in is a semantic change and demotes an enforcing rule back to report-only. A system approval deliberately carries no human name: the execution record is the approver, because an audit trail that names a person who did nothing is an audit trail that lies.
- Consequential actions with promotion gates: isolate a device, and accept or close a risk. Isolation requires fourteen days of demonstrable report-only running at the rule's current version. The clock starts at the first execution and restarts on any semantic edit, because a rule that merely existed has not been reviewed by reality. Accepting and closing additionally require a named, active human owner, re-verified at the moment of promotion.
- Limits on how far an automated action can reach: a rule that would isolate more than a configured fraction of the fleet, by default a quarter of that client's devices, halts the entire action list and notifies administrators rather than proceeding. A per-run cap truncates with the overflow recorded, never silently. Already isolated, offline and already queued devices are skipped with the reason recorded. A rule can never re-isolate a device that lifted its own isolation during an outage, because that is a containment loop and it stays human. Automated risk acceptance is forcibly time-boxed, between one day and a year, so the expiry checker always reopens it and automation can never quietly become permanent suppression.
- Twenty curated starter rules as a library, because an empty builder is a feature nobody adopts. Among them: notify and ticket on critical CVE risks, risks with no owner, Microsoft 365 posture and confirmed investigations; patch automation including the full loop from critical security patch detected to deployed inside the maintenance window; and one deliberately narrow example of time-boxed acceptance of low-scoring noise. Installing one goes through the same guarded path as a hand-built rule.
- Cross-client response intelligence: as soon as a detection at one client meets the bar, its structural signature becomes a campaign. Hard indicators are pushed as block rules to every other client in the same partner scope and applied on the next heartbeat, and every heartbeat in that scope is scored against the signature for 72 hours, then on indicators alone for a further seven days. A confirmed match opens an investigation. A blocked attempt to call back to a command server counts as a confirmed hit in itself, because the block proves the machine tried. Client-identifying data is stripped from a signature before it crosses between clients, a safelist prevents shared infrastructure from being blocked, and spread across more than sixty percent of a fleet auto-suppresses the campaign, because that pattern is a rollout and not an attack.
- Compliance checks carry their evidence: the thirteen device checks moved into a versioned registry where thresholds are declared as data and every verdict returns the observed value. The report and the email can now name the measured value instead of only pass or fail. The evidence appears on the failing devices in the compliance report, on the device page, and in the emails about status transitions. The verdicts themselves are unchanged: the evidence is what turns adjusting a threshold into an arguable decision rather than a silent one.
- Custom rules mapped to framework controls, rendered as coverage on the compliance report, and rule presets as versioned content.
- Device coverage against Entra and Intune: a card on the tenant page answers how many of the devices registered in Entra Secuno actually covers, with the split between exact matching and hostname matching, the overlap with Intune, the count of agent-only devices and a sample of registered devices with no agent. The denominator counts enabled registrations only, because tenants accumulate stale disabled device objects that drag the percentage down on their own.
- A removable media audit trail: USB insertion events are now kept separately and queryably rather than only inside an investigation's evidence, with their own card on a device's Security tab.
- Stale local account detection shipped as check engine content rather than a new detector: the evaluator gained rolling-window conditions, and a preset ships for an enabled local account unused for ninety days. The threshold is editable and the preset is report-only by default.
- Fleet-wide timings on the investigations page: time to detect and time to acknowledge as two cards, measured on the timestamps that are actually set.
- Smaller work that shows up daily: an ambiguous mention of a colleague no longer silently notifies whoever the query returned first but says the handle matches more than one person; mentioned users get an email behind a new preference that defaults to on; the Jira connection test now also proves the project is visible and the issue type exists inside it rather than only that the credentials work; and the output both agents already wrote to the event logs is documented with paste-ready examples for the common collectors.
Fixed
- A blocked attempt to call back to a command server was discarded once it fell below the per-heartbeat cap, even though it was the strongest signal the pipeline produced. Such attempts now open an investigation.
- Re-acknowledging a block wiped the recorded method by which that block had been enforced.
- Delivered block rules persisted and were re-sent on every heartbeat. They are now collected after thirty days.
- The preset for an open port above 1024 compared on equality rather than greater-than. Fixed as a new version of the preset with real comparison operators, so stored rules keep their meaning.
Changed
- Every automation rule starts report-only, including the ones from the library. There is no way around it: promoting is an act by a platform administrator, and for consequential actions a period of demonstrable running comes first.
- Killing a process and quarantining a file are deliberately not automation actions. Both are driven by a process id or a path, and no server-side event carries that data in a contracted form. A process id taken from an older investigation has since been recycled and would point at an innocent process. Killing at the moment of detection already exists in the right place, in the agent's own rule engine. Releasing containment likewise stays a human act.