Version History

Version 3.7.0 — In development

Three things arrive together.

• Highwind AI stops waiting to be asked and tells you when a protection on the machine has been weakened.
• App Control is reorganised around the outcomes administrators want — block this, allow that, am I ready to enforce — and gains a shared decision list in SharePoint.
• A preview of Fleet central management lets you run your own management server so devices can be seen and asked questions centrally.

Fleet portal: what needs attention, what changed, and Ask Highwind

The Fleet portal keeps every number it had and adds a way in. Dashboard, Devices, Security posture, Firewall and App Control now open with a short strip of insight chips: a plain label, a count, how it compares with before, and one click to the exact devices behind it.

Chips are ranked, not fixed: a critical security gap or a widespread outage comes first, routine noise stays out of the way, and the order does not jump around for small changes. Each page shows only the chips it has real data for, and says so when a source could not be read.

• What changed (new /changes page): last 24 hours, 7 days, 30 days or your own dates, compared with the period before, across security posture, App Control, the firewall and the timeline. It says “12 more devices have a high-risk finding than yesterday”, never “+12”, and it never claims one change caused another: firewall rule changes are labelled correlated, likely related or possible, with the evidence.
• Scope: when a problem is concentrated, Highwind says what the affected devices share (a tag, site, environment, agent version) and compares against the relevant group, not the whole fleet.
• Ask Highwind (new header button and /ask page): ask in plain words. Answers are built from your own Fleet records through the same permissions you have, so you can only be told about devices you can see. Every line is labelled Observed, Correlated, Likely related, Possible explanation, Insufficient evidence or Unknown, with links to the evidence, the time range, freshness and what is missing. It does not change anything on a device. By default no language model is involved; an administrator can opt in (Portal:Ai), and the model only ever sees the bounded evidence, its wording is rejected if it adds numbers or claims a cause, and the plain summary is shown instead.
• Machine-level questions and change review: name a device and a time in Ask Highwind (“What changed on PC-01 in the last 8 hours?”). Changes are sorted into what needs a look, settings that keep changing (possibly two sources setting them differently), and routine noise. Highwind shows where a setting can come from and how to check, but does not record which tool set it. The device page now opens with a Quick status panel built by rules from the device’s posture and last 24 hours of changes.
• Policy settings: who sets what (new Settings page and Policy settings on every device): every Group Policy, Intune and Defender setting a device holds, with its value and what set it (the Intune enrollment that won, or the named Group Policy object), the settings that changed most with before and after, contested settings (two sources, or a value going back and forth), and settings that differ between devices. Opt-in per device (Allow policy settings report). Ask Highwind has a Who sets what group of questions. A value Highwind cannot tie to a source is shown as Not attributed, not guessed.
• Setting changes grid: What changed and the device Timeline now show every setting change with before and after, plus a ranking of the settings that change most across devices, what each setting does and what can go wrong. The What changed page has a device-name filter and smaller range buttons.
• What changed, redesigned: the page opens with the settings that changed the most, then chips for each Defender area (real-time, cloud, tamper, attack surface rules, network, controlled folder access, updates) and each Windows area (firewall, boot and hardware security, App Control, device control, hardening). Each chip shows its change count, devices and what needs a look; one click opens that group's before and after grid. See every setting change shows everything. Up to 1,000 changes are read (was 100).
• App Control rule builder and scans: a Step C appears when files are still left after the main rule and the fallback. The agent now checks whether a file's folder is writable by ordinary users (read from the folder permissions) and the portal refuses path rules for those files. The Applications list has a Scanned column with file count, signer, unsigned files and user-writable folders. Windows does not log allowed files, so only Blocked and Would block are counted.
• Client configuration from the portal: Admin › Client configuration lets an administrator switch the agent’s reports on or off (policy settings, firewall, App Control, file scans, kernel, persistence, software trust, AI security, health, custom queries, last user) for all devices or per tag. A tag wins over All devices, and a value the portal sets wins over local ADMX; reports left Not set stay under local policy. Devices apply a change at their next heartbeat. Sign-in, the service address, lab changes and AI egress can only be set on the device, and a new ADMX policy, Accept client configuration from the management portal (FleetPortalConfigurationEnabled), lets a device ignore the portal. Needs the new database migration ManagementRound43, the API, the portal and the agent (MSI).
• One-click issue detail: on Posture, opening an issue (or its chip) now shows what it is, why it matters and, per device, what the device reported — for the ASR check, each rule and its mode. The Access page’s tag picker and permission boxes are laid out left-aligned in grouped cards.
• Chips open the answer: Changes chips open the Timeline as an event list for the same period and filter; Dashboard “Not checking in” and “Report is behind” open Devices filtered to the silent devices (new Not checking in quick filter); App Control chips open the device list with findings or oscillating devices; Posture device rows show their findings already expanded when you arrive from a chip.
• Shared AI core: the wording rules, evidence labels, redaction, tool allow-list and Azure OpenAI chat provider live in Highwind.AI.Core. The Client’s feedback service uses the same protocol but has not been moved onto it yet.

App Control: By application and scanner rule order

Advanced Hunting has a new By application view next to By publisher, grouping events by application with devices, files, would-block counts, versions, hashes and the rules needed.

The App and File Scanner now honours your rule precedence in the Recommend column as soon as you change it, and files scanned through an administrative share (\\localhost\C$\…) are recognised as local protected paths, so a FilePath rule is no longer skipped in favour of a hash.

Fixed: Advanced Hunting reports a file’s folder together with its name, which made path rules end in file.dll\* and never match, so they showed as Would Still Block after Compare. Path rules are now built for the folder.

A new device box next to the day and row limits queries one or more devices instead of the whole tenant, and filters added to the query now always land in the main query rather than the signer lookups.

The application Rules window has a new Save as supplemental… option: pick the base policy and the rules are saved as a supplemental policy attached to it, with its own PolicyID; the base is not changed, and you are warned if the base does not allow supplemental policies.

The expanded application view now fills the width, popup windows can be moved, and Policy Comparison and Policy Merge are working screens where you gather policies from files, a folder or this machine and then compare or merge them.

App Control menu: Policy Comparison and Policy Merge are now one "Compare and Merge" page with three tabs (Policies, Compare, Merge), so nothing opens in a separate window. To merge, pick a master policy; the other ticked policies have their rules added to it, the master keeps the policy options (such as Audit mode), and the result is saved as a new policy with a new Policy ID.

The Policies page moved to Endpoint Tools > Local Policies, now showing policy names first.

App Control menu: "Endpoint Tools" is now Local Endpoint and sits above Investigate. Events moved into it (next to Local Policies, Device Status and CiTool). Device Status now shows the Code Integrity policy, VBS, security services and Smart App Control state instead of a placeholder.

Installed applications scan is faster: files are now read several at a time, each file is read once for both hashes, and the machine’s enforcement state is looked up once per scan instead of once per file.

The App Control page also documents the Advanced Hunting sign-in permissions: what the consent prompt asks for, where approval requests go, how to review grants and how to remove your own to repeat the sign-in.

Installed applications: products that leave no install path in the registry (for example Global Secure Access Client, .NET runtimes and agents) are now located by matching the application name to a folder under Program Files, and show "(found by name)" in the Source column. Broad vendor folders such as Adobe or Microsoft are never guessed.

Installed applications: scanning now only lists applications by default. Tick the ones you need and choose Check selected, or Check all, to read their files and work out recommended rules. Turn on Check files while scanning to keep the old all-at-once behaviour. Creating a policy checks any ticked application that has not been checked yet.

Fixed: some Windows Installer products (for example ODBC Driver 17 and System CLR Types for SQL Server) showed an install folder of C:\?\WINDOWS and "Folder missing". Placeholder paths are no longer treated as folders.

App Control menu: App and File Scanner is now first under Deploy App Control, and Block Applications and Allow Applications use its scan results when Advanced Hunting has no events loaded. Impact Scanner and Enforcement Readiness moved under Investigate, because they work from Advanced Hunting results.

Highwind Fleet: the portal is a free trial, for as long as you need up to one year, but a license file is still required (it tells us who is using the portal) and pricing may change in the future. Azure is the only supported way to host the portal and API today; an on-premises install is coming soon.

The Local File Scanner is now the App and File Scanner, since it scans folders and installed applications on this device or, through an administrative share or Scan device, on a remote one.

Block Applications and Allow Applications now also use the installed applications you have checked (previously only scanned folders showed up), list separate files of one product (for example 7-Zip’s 7z.exe and 7zFM.exe) by file name, and have a compact layout, a full-height application list and a hint while nothing is selected, matching the other App Control pages.

App and File Scanner:

• One Create policy button now works on whichever tab is showing (scanned files or ticked installed applications).
• The rule precedence editor uses the same drag-to-reorder design as Advanced Hunting, and changing the order updates recommended rules immediately.
• Scan device scans a remote machine through its administrative share; rules are written with that device's local paths, and signatures are checked against this machine's catalogs.
• Installed applications shows a progress bar and per-row "Checking recommended rules" while it works.
• Advanced Hunting sign-in now times out after 3 minutes and has a Cancel sign-in button if the browser tab is closed.

Policy Comparison and Merge:

• A rule found in just one policy is now labelled "Only in one" (rules in two or more but not all show "In 2 of 5"), with its own count and filter.
• A FilePublisher signer is no longer treated as the same as a plain publisher signer.
• Merge now writes the signers and file rules into the signing scenarios, so a merged policy actually applies them (before, it listed them but nothing used them), and an Allow and a Deny for the same file are both kept.
• The old Diff / Merge button on the Policies page was removed; use Policy Comparison and Policy Merge in the App Control menu.

Fixed: a path rule written with the %OSDRIVE% macro never matched anything in Compare (the drive was expanded with a doubled backslash), so applications installed under Program Files kept showing as blocked. By application now shows Files blocked and Files allowed rather than event counts, and searching no longer changes which application a file belongs to.

🔥 Endpoint Firewall Reporting (Fleet)

Fleet now answers “is the firewall healthy, what is blocked, what is allowed, and why?” from the devices you already manage.

Simple first, details on demand: an Overview with three lenses (Overview, Security, Troubleshooting), a Needs Attention list, Top Blocks and Top Allows, a Rules view, a firewall section on every device and a “why was this blocked or allowed” page.

Troubleshoot, Exposure and Baseline:

• Troubleshoot explains a blocked connection from a device, application, destination or port, with honest attribution (exact rule, likely rule or not attributed) and how widespread it is.
• Exposure separates listening ports, firewall-allowed ports and observed inbound traffic.
• Baseline shows rules that differ from the fleet, or from devices in the same environment, organizational unit, tag, join type or Windows build.
• Networks shows which of your networks talk to which and flags new or unusual relationships for review.
• Changes lists rule and profile changes across the fleet and checks blocking before and after the widest ones, with honest wording when the evidence is thin.
• Applications lists each program with allowed and blocked counts, destinations, countries and networks, and flags new destinations (new is not malicious).
• Health score explains every point taken off.
• Risky rules flags wide-open rules, search and saved views find and keep pages, and the evidence report downloads a Markdown summary with its limits.

All read-only; listening ports need the updated agent, and saved views need the updated database script.

• Built-in GeoIP. Highwind ships its own offline location and network-owner database (MMDB, DB-IP Lite), so connection locations work with no setup and nothing leaves your deployment. Add a city file, or any MaxMind-format database, for region, city and coordinates, and tag subnets GeoIP does not know. Updated between releases by replacing the files.
• Compact pages for large fleets. The Overview stays high level (cards, dashboards for connection locations, top destinations and top blocks). Needs attention and a compact Devices list have their own pages, with filters for devices that need a look, devices with no concern, and late data. Rules that Windows reports twice (a local copy and a policy copy) are now shown once, as the copy in force, and policy rules are labelled GroupPolicy or Mdm instead of Local.
• Country names, direction and ports. Locations read Hong Kong SAR (HK) instead of HK. Remote-address rows in Top blocks and Top allows now say whether the traffic was inbound or outbound and which ports it used, for example "Outbound, port 443 (HTTPS)". Top blocks and Top allows also have Both directions, Inbound and Outbound buttons, and remote-address rows name the devices involved when there are three or fewer; with more, the Devices number is a link that lists them (Top allows also gained a Device view). The built-in location data now includes the city (DB-IP City Lite). City is approximate and is often missing or wrong for VPNs, mobile and corporate gateways, where it shows as unknown; country is the reliable signal.
• WFP Events page in the desktop app. Firewall now has a WFP Events page that lists the Windows Filtering Platform audit events (Security log 5152, 5153, 5156 and 5157) on this computer, with a time range and a filter box. If the audit policy is off, the page says so instead of showing an empty list, gives the two auditpol commands (and the Group Policy path) to turn it on, and links to the Microsoft Learn pages. Highwind never changes audit policy. Needs an elevated session; hide or show it with the new VisibilityWfpEventsPage policy (ADMX updated).
• Servers and workstations are tagged automatically. The agent adds a Workstation or Server tag (and DomainController on domain controllers) from the Windows product type, ahead of any tags you set. Use the tags in policy scopes and in Baseline “Compare with” (each tag is now its own group). Devices get the tag after they run the updated agent and report. No schema change.
• Who changed a firewall rule. The agent reads the Windows Firewall log (events 2004, 2005 and 2006, on by default) and the Changes list shows the account and program that added, changed or deleted each rule. Needs migration ManagementRound39 in fleet-schema.sql.
• Which rule blocked it. The Why column on the Events page and the device page now names the rule or filter that decided the traffic, when Windows still knows it.
• Where devices connect from. The Fleet API now remembers the public address each device checks in from and places it with the built-in location data (no outside service is called). The firewall device page lists the locations for administrators, and Needs attention flags a device that checks in from a country it has not used before. A VPN shows the VPN's location. Apply the updated schema script (new DeviceLocations table) before deploying.
• Filter by device name. The firewall filter bar takes a device name, with suggestions as you type, instead of a device ID. The device page now splits top blocks and allows into Inbound and Outbound. New inbound rules always show under Important changes, even when they only apply to the local network.
• Connection direction fix. Windows labels inbound and outbound events the other way round from what the agent assumed, so local and remote addresses were swapped. The new agent reads them correctly. Events already stored keep the old labels until they age out. The device page now lists top blocked and allowed remote IPs and its recent events show protocol, local and remote endpoints, location and application.
• Network profile switching. The agent already notes each time a device changes between Domain, Private and Public. Needs attention now flags a device that changes six or more times in seven days (Medium at twenty), so unstable links and VPNs that keep reconnecting stand out.
• Calmer change list. A device’s Changes shows the latest 200 and opens on Important, hiding routine housekeeping; choose All changes to see everything. A new Hide multicast and local choice in the filter bar removes multicast, broadcast and link-local traffic from Top blocks and Top allows. The agent now reads a profile’s default inbound action of Block correctly (it showed as Unknown before). Needs the new MSI, API and portal; no schema change.
• Three separate things. Profile state, rule state (effective, not just configured) and connection activity are collected and shown separately. Metadata only — never packet contents.
• Honest attribution. A decision is only tied to a rule when the evidence supports it; otherwise Highwind says “Windows reported the traffic decision, but the available telemetry does not identify an exact firewall rule.”
• Internal IP Space. Name your corporate, VPN, datacenter and partner ranges (IPv4 and IPv6, import/export, overlap checks, audited) so traffic reads as internal or external. Public addresses can be enriched with an imported country/ASN table; private addresses are never looked up. Location is labelled approximate.
• Light on endpoints. Incremental rule collection, bounded batches, deduplication, volume limits and dropped-event counters. Recent raw events are kept 14 days (Admin only); hourly aggregates 180 days. Both are configurable.
• Timeline and findings. Profile changes, new broad inbound rules, block spikes and stale collection appear on the Security Timeline; a connection never does. Trust and posture scores are unchanged.
• No device changes. Windows audit policy is yours to set; Highwind reports readiness and gives plain guidance. A new FleetFirewallReportingEnabled ADMX policy turns the collection off estate-wide.
• Tag baselines and several tags: a device that carries more than one tag (for example the automatic Workstation tag and your own DEV tag) now gets its tag baseline. The Posture grid shows the baseline as Default + DEV when a tag baseline is layered over the Default one. The Fleet documentation has a new Firewall reporting guide.

🧠 Highwind AI

👀 Security Watch

Highwind already keeps 30 days of configuration history. Now it reads that history on its own — two minutes after launch and every two hours after that — and looks for one thing: a protection that was weakened or removed from policy. Signature updates, scan counters and other routine churn are ignored.

• Quiet by design. No pop-ups. Findings are waiting as suggested questions the next time you open Highwind AI — “How do I fix this – BitLocker was weakened?” — at most two at a time, each raised once.
• Only news. Changes from before the watch first ran are not announced, so turning it on does not flood you with 30 days of history.
• Honest about gaps. With too little history it says so, rather than implying an all-clear.
• Consoles fighting. Highwind also spots a setting that keeps flipping back to a value it already had — the signature of Intune and Group Policy overwriting each other — and says so when you ask about settings history.
• Centrally switchable. The new AllowAiSecurityWatch policy (default on) turns the watch off for a whole estate. The ADMX now also has a Highwind AI folder with the existing online-lookup, model-reasoning, iteration and research-source controls, which were previously registry-only — see registry reference.

📌 Pinned prompts and a proper prompt library

• Pin the questions you ask every day (up to 12). Pins replace the starter suggestions and are kept per user.
• A categorised prompt library — onboarding and sensor, antivirus, ASR, exclusions, App Control, firewall, device control, event logs, and “write it up for someone else” — which folds away once you start asking.

🔧 Better answers

• New questions it can answer: device configuration, USB and Device Control, platform support (“is this supported on Server 2016, macOS, Linux?”) and App Control analysis.
• “How do I fix it?” goes straight to the remediation, and answers suggest sensible follow-up questions.
• You can see how an answer was produced. The badge distinguishes model-assisted, model analysis only, model planning only, and local rules.
• Azure OpenAI is now called Microsoft Foundry throughout, matching Microsoft’s own naming. Configuration is unchanged.

🖱️ Readable at any scale

Highwind now follows the Windows Text size setting and per-monitor DPI, and reacts live when either changes. The main window is capped at 150 % so dense grids stay usable; the chat and pop-out answer windows scale fully.

🛡️ App Control

• Outcome pages. Deploy App Control now has Block Applications (with blast radius), Allow Applications, Impact Scanner, App and File Scanner and Enforcement Readiness (with history). Rule Recommendations moves under Policy Management; Local Policies sits in Endpoint Tools. Tour the pages →
• Add to an existing policy. Append rules to a policy you already have rather than starting over. PolicyID is kept, VersionEx is bumped, a .orig.xml backup is written, duplicates are skipped and counted, and a change-log comment records what was added. Add to Local Policy applies it on this machine with CiTool.
• Checks the real file. When the binary is on this machine, Highwind confirms it is the file the event describes (SHA-256 or Authenticode hash), verifies the signature with Windows, including catalog signing, and anchors publisher rules on the real signing certificate. How it works →
• SharePoint Decision Store. Keep application decisions in one SharePoint list your decision board can open in a browser. Sync is incremental and never overwrites a decision; disagreements are reported. Off unless enabled by policy. Set it up →
• Advanced Hunting, tidied. No more overlapping controls, a collapsible Action Plan, a live “uses N rows” count next to Export, and grid columns that remember their order, width and visibility. Window size and position are remembered too.
• Compile to .cip is on by default.
• Demo mode for presentations and training, enabled by machine policy only. All data is synthetic and nothing is saved or uploaded.

🌐 Fleet central management Preview

Host your own Highwind Management API and Portal. Devices running the optional Highwind Fleet Agent service register, send heartbeats, advertise what they can report, and answer approved read-only questions on demand.

Operators use the Portal or the API; every request is authorised by role and audited, and a device will only run an operation it has advertised.

• Step-by-step Azure deployment (Entra app roles, Entra-only Azure SQL, App Service with managed identity) and a verification script that checks a deployed site end to end with real Entra tokens.
• Deploy to Azure with Entra ID app registrations for the API and Portal, and roles for agents, operators and administrators.
• Zero-touch device identity: Entra joined and hybrid joined devices prove their Entra device identity and receive a 30-day, service-issued certificate (Key Vault HSM key); no client secret on endpoints. Administrator or automatic approval. Details.
• Ask devices from the Portal: ask one device, or run a query across the fleet, for Defender, ASR, App Control, device control, firewall, compliance, installed software or Highwind configuration. Results show as a grid and download as CSV. Details.
• Simulation Assurance (first step): a simulated change can now be sent to Validate this change. Highwind saves an audited run with an evidence score (the quality and completeness of the evidence, not a probability), the impact knowledge for that kind of change, a representative canary with matched unchanged controls, an observation plan and what is still unknown. Nothing is changed on any device. If you tried the change on a pilot group elsewhere, you can record the counts and Highwind compares changed devices with unchanged controls (before and after) so ordinary background problems are not blamed on the change; the counts are entered by you and not verified by Highwind. New: devices that opt in to FleetHealthSignalsEnabled report whole-hour counts of crashes, hangs, service failures, unexpected restarts, App Control and ASR events and failed sign-ins (counts only, never event text, users or file names; the first report already covers the last 72 hours), and an administrator can click Start observing on a saved run to have the plan’s devices report hourly for a limited time and see what normal looks like for each signal. Needs database migration ManagementRound34. For a canary, an administrator can approve the plan, record when they applied the change (for example to an Intune pilot group), and have Highwind compare the canary and matching control devices before and after from the signals already collected. By rule, a worsening comparison pauses the run (audited; you stop the rollout where you applied it, then resume after review) and a clean one lets you plan the next wider wave (5, 25, 50, 100 percent of the devices in scope, never the controls), record when you applied it and compare again. The Simulation page also takes up to five settings at once with the + button. The run report also shows a track record from this tenant’s own earlier runs of the same kind of change (older runs count less, other tenants are never used; a record, not a prediction). Highwind still does not apply the change, confirm it reached the devices, or pause or roll it back; you make changes in your own tools. See the Fleet documentation, Simulation Assurance.
the security-change simulation moved from Last barrier to its own What if tab in Posture (/whatif); old /horizon?ctl= links redirect. The Device control pages take any look-back of 1 to 400 days (default 7) from a number box; longer ranges use stored history and fall back to each machine’s latest 7-day data until history fills.
• Device Control blocks and paged posture pages: a new Device control page lists devices where Defender blocked a removable device, from the Defender device-control log the client already reads, with the type, brand and model of each (USB drive, CD/DVD drive, printer, phone), a Devices view across all machines, and a page per machine, each with a last 7 days, 30 days, 90 days or 1 year filter. Device history is kept per machine, device and day (365 days by default, DeviceControlHistoryRetentionDays) from the time the updated agent and server are both in place; older agents add nothing to it. Kernel, AI, Software and Timeline now load one page at a time with totals for the whole tenant (the timeline reaches about 4,000 recent events). Device Trust gains an “Adds to overall score” column. AI agent runtime protection (Preview) is now read and shown on the overview, scored, available to the AI assistant and reported by the Fleet agent as a baseline setting. New protections can be added through a table rather than a release. The Device control look-back needs the latest database migration; without it the pages show the last 7 days and say so. New invariants mean some existing devices will show Violated or Unknown after the update.
• Security posture and drift: a new Posture page shows every device’s effective Defender, ASR, App Control, firewall, device control, BitLocker and compliance state, keeps itself current (every 4 hours by default), and refreshes on demand for the fleet or one device. Findings come from fixed rules and from drift against your own fleet — a missing or older App Control policy, an ASR rule in Audit where the rest block, an agent or Defender platform behind. Top issues, filters and CSV export. Details.
• Posture baseline: administrators set what every device should report — each Defender setting, every ASR rule, App Control enforcement and policies, firewall profiles, device control, compliance checks — with a severity per setting. The page shows what the fleet reports today and how many devices already match, and can pre-fill from the fleet majority. Differences appear on Posture with a baseline badge. Tag baselines give servers, labs or a pilot ring their own standard: they override the default only for the settings they list, and a device uses the one for its tag, org unit or environment. Details.
• Custom queries in plain English: write HKLM\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL = 1, service Sense is running or file %SystemRoot%\System32\drivers\x.sys does not exist with suggestions as you type, ready-made recipes and a did you mean? hint that fixes near-misses when you choose Yes; preview what the portal understood, save, and every device answers compliant or not in about a minute, with a compliance-by-check summary and CSV. Read-only, fenced to safe registry and file roots, re-validated on the device, and off unless the device’s policy allows it. Details.
• Device groups and per-group permissions: devices report their Highwind tag, org unit and environment. Filter, sort and target queries by tag. Admin → Access gives an Entra group (or user) a set of devices (tags, or all) and a role — Read only, Operator, Device manager, Policy author, Enrollment officer, Delegated admin, or any mix of seven permissions — and the service enforces every one. Details.
• Admin area: Access, Enrollment, Device identity, Baselines and Custom queries sit under one Admin link at the far right, showing only what the signed-in person may manage.
• Accountable enrollment secrets: minting a secret requires a justification; the list and the audit event record who minted it and why.
• Built for 700k devices: check-in and posture intervals are configurable and jittered, routine heartbeats are no longer audited, posture reads one row per device and question, cleanup runs in bounded batches, and a scale bench ships in tools. Sizing guidance.
• Saved queries and history: save any query with its target, rerun it in one click, and see the last 50 queries with who ran them. Query results open the full answer in a full-width row and export one row per item (each installed application, ASR rule, policy or check) as well as one row per device.
• Check in now / Full posture sync: two clear device actions — confirm a device is alive within about a minute, or have it collect every posture answer at its next check-in.
• Portal pages no longer load blank: nested pages (a query’s results, a device after Approve) could stay on Loading… or render unstyled because the content security policy blocked their relative stylesheet and script paths.
• Database housekeeping: finished requests and their answers are deleted after 30 days (CompletedMessageRetentionDays).
• Posture reports: Overview, Baseline compliance (each setting, which baseline set it, % compliant, drill-down to the devices that miss it), All issues (by area) and Devices tabs, each with its own CSV and a tag filter that recounts everything. Issues show % of devices and a badge naming the baseline — Default or a tag — that raised them, and every device shows the baseline it was judged against (for example DEV + Default). Details.
• AND / OR in custom queries: …\DefaultEnforcement = 1 or 2, … is one of 1, 2, 3, file A exists and file B exists, service X is running or service Y is running — up to five conditions in one check. Needs the matching agent. The editor gains a full-size text box, a ✕ on every line to remove it and Clear all. Details.
• Standard Entra groups: New-HighwindFleetGroups.ps1 creates Highwind Fleet Admins, Read Only, Operators, Device Managers, Policy Authors, Enrollment Officers and Delegated Admins with their app roles and Access assignments, so every tenant is set up the same way. Details.
• Who and where you are: the portal header shows the tenant name (set in Admin → Access) and your role (Full admin, Device manager…), with the exact permissions on hover. The dashboard is titled Highwind Fleet and the portal carries the Highwind icon.
• Sizing and protection guidance: recommended Azure SQL and App Service sizes from 2,000 to 700,000 devices, and how to protect the service (Front Door WAF, DDoS Network Protection, private endpoints, device proxies). The API rate limit is now per tenant (Fleet__RateLimiting__TenantRequestsPerMinute, default 120,000) and per caller (…CallerRequestsPerMinute, 600); previously 600 per minute applied to a whole tenant, which throttled fleets above a few hundred devices. Sizing · Protection.
• Posture trend: the API takes a daily snapshot of the whole fleet and of each tag (score, % baseline met, high findings, drift, stale devices, top issues), and Posture → Trend charts it over 30–365 days with the change since the start and a CSV. Kept 400 days. Details.
• Saved views: save a Posture report with its filters under a name, privately or shared with every operator, and reopen it from the bar at the top of the page. Details.
• Scheduled CSV exports: administrators schedule any posture report daily or weekly, for every device or one tag (Admin → Scheduled exports). The service builds the file over the whole fleet, keeps it compressed in your database for 30 days with its SHA-256, and only ever hands it out through the authenticated API — there is no destination to send it to. Details.
• Faster paging for large fleets: the device list and posture report continue from where the last page ended instead of counting past every earlier device, so page 6,000 is as quick as page 1; beyond the portal’s live page limit, Posture shows the whole-fleet numbers from the latest snapshot. Needs the schema with migration ManagementRound5. Details.
• Activity log: Admin → Activity log shows who did what in the portal and API, by name, with what devices and the service did alongside; filter by person, action, outcome, device and dates, and export CSV. Administrators only; reading it is audited. Details.
• Which baseline applies: Posture → Baseline compliance groups devices by the baselines that judged them (Default, DEV + Default) so a tag’s settings are never mixed up with the whole fleet’s; the CSVs carry the same columns.
• App Control management (optional, off by default): a fleet-wide inventory of the App Control policies actually running on each device, expected policy sets per tag, OU or environment, and findings for missing, outdated, inactive, audit-only and unexpected policies, with rollout by group. Visibility Only in this release: no new device traffic, no agent change, nothing deployed. Details.
• App Control policy sets, drift and trend: every device's active App Control policies are reduced to one policy-set fingerprint (IDs, versions, binary hashes, options, audit or enforce), so you see how many distinct combinations the fleet runs, which groups are fragmented, and exactly what differs between any two. Devices are Matching, Drifted, Pending convergence, Stale, Incomplete, Unknown or Collection failed — never compliant on missing or partial data. History catches devices flipping between policy sets; Convergence shows how long devices took to match after you changed an expected set; Trend keeps a daily point. Each expected set states its strategy (allow-list or deny-list). Needs migration ManagementRound7; update the agent for hashes, options and the Windows build. Details.
• App Control alerts and notifications: drift becomes stateful alerts — one per expected set and policy, never one per device — for drift, missing, unexpected and outdated policies, audit-instead-of-enforce, stalled rollouts and stale or failing collection. Alerts raise once, count repeats, resolve themselves when the condition clears and escalate when nobody acknowledges them. Work them on App Control → Alerts (acknowledge, assign, suppress, resolve, close; every action audited, concurrent edits refused). Optionally send them to Microsoft Teams or a signed HTTPS webhook: channels live in configuration and Key Vault, messages carry counts and a link but never device names, delivery retries with back-off and a per-channel throttle. Needs migration ManagementRound8; no agent change. Details.
• App Control applications and the Application Control Board: an application catalog built from installed software and App Control audit/block events reported by devices, plus Defender Advanced Hunting CSV imports (de-duplicated, re-import safe). Records are matched on their strongest identity (package family, signer + product + file, publisher + name, hash last), never on similar names, with confidence shown; administrators can merge or separate records with a reason. The new Governance mode adds the Board: reviews with owners, justification, security and technical reviews, decisions (approved, approved with conditions, denied, temporary exception, deferred), expiry and recertification, four new Access roles and separation of duties (a reviewer cannot decide their own review), every step audited. Device evidence needs both a tenant switch and the new device policy FleetAppControlReportingEnabled (off by default). Decisions change no policy. Needs migration ManagementRound9, the new agent and ADMX. Details.
• Board decision alerts: Highwind checks that the fleet follows the Board. Approved but still blocked when an approved (or excepted) application is blocked after the decision; Denied but still running when a denied application still runs in audit mode. Only events after the decision count, one alert per decision, linked to the application, never naming devices; it resolves itself once the events stop (DecisionEvidenceDays, 7). Needs migration ManagementRound10; no agent change. Details.
• App Control rule recommendations (mode Recommend): for a Board decision, Highwind builds rule candidates from the application’s own events, deterministically and most maintainable first (package family, signer + product, file publisher, file attributes, protected path with written risk acceptance, hash), with coverage, breadth and narrow risk, target base or supplemental policy, conflicts, known gaps and deny impact. Never a publisher-wide rule, a user-writable path, or a path deny. New roles Rule author (generate, propose) and Rule approver (approve, reject), separate from each other and from the decision maker. Approval changes no policy. Review states Needs rule, Rule proposed, Rule approved. Migration ManagementRound11; settings Fleet:AppControlRules.
• App Control rule impact simulation (Policy simulation switch): simulate any candidate, proposed or approved rule against recorded events and the policies devices reported. Allow impact (blocked events projected to be allowed, devices fully or partly unblocked, other bases that still block), deny impact (executions and devices that would be blocked, installed devices, critical Windows/security/management components, installers and updaters, approved applications affected), per-device outcome, group and Windows-build breakdown, conflicts, and missing, stale and not-evaluated data. Every figure is labelled Observed, Projected or Unknown. A proposed rule can be approved only with a current simulation of the same rule (configurable). Reads telemetry only. Migration ManagementRound12; settings Fleet:AppControlSimulation.
• App Control application files (Application file scans switch, FleetAppControlFileScanEnabled): open an application and choose Scan files. Up to 5 devices that opted in list the application’s executables, libraries, installers and scripts (version, signer, issuing certificate TBS hash, Authenticode SHA-256). The page shows every file, which block now or would be blocked when enforced, and the fewest rules that allow them in your preference order. Read only.
• Persistence audit (FleetPersistenceAuditEnabled): opted-in devices report what starts with Windows or a sign-in (local administrators, non-Microsoft scheduled tasks, Run keys, Startup folder) with hash and signature state. Each item is rated Expected, Unknown, Suspicious or HighRisk with the reason shown; new and removed items appear in Recent changes; administrators can approve or deny a finding.
• Software trust (FleetSoftwareTrustEnabled): opted-in devices report the programs running now with SHA-256, version, signature (embedded or Windows catalog) and the signing chain to the root. The portal shows who signed each program, which root, how many devices run it, other software from the same signer, other versions seen and whether App Control signer rules cover it, at Posture > Software trust and on each device. A program replaced by different content, or a new unsigned program in a user-writable folder, is recorded as a security change.
• Kernel assurance (FleetKernelAssuranceEnabled): opted-in devices report Secure Boot, TPM, virtualization-based security, memory integrity, Credential Guard, kernel code integrity, the driver blocklist setting and the drivers they run. The portal shows an explained Kernel Trust score (every lost point lists its evidence, reason and fix) at Posture > Kernel trust and on each device. A protection turning off, a new non-Microsoft driver or a changed driver is recorded as a security change.
• AI and MCP security (FleetAiSecurityEnabled): opted-in devices report AI products (desktop apps, coding agents, local runtimes, editor extensions), the MCP servers in their configuration files, local model files and AI listening ports. The portal shows an AI Asset Passport per product (shell, PowerShell, file and network reach, pre-approved commands, credential stores in reach) and an explained AI/Agent Trust score, at Posture > AI and MCP security and on each device. Administrators approve or deny each MCP server; an approval is voided if the server's command, program or reach changes. New servers and changed commands, programs, destinations or permissions are recorded as security changes.
• What-if and AI state in Horizon: the Last barrier page (/horizon) also has a fleet What if that counts how many devices a proposed value would weaken, and lists the worst. A device's Horizon page has a What if form. State up to three values (for example kernel.hvci = off) and see which invariants and dangerous states would change, with an outcome of Weakens, Strengthens, Uncertain or NoEffect. Nothing is applied. The AI containment invariant now reads the device's stored AI Security report, so it no longer stays Unknown on devices that reported.
• Remediation what-if: a remediation plan page now shows a Horizon effect panel: which invariants and dangerous states would recover, strengthen or get worse for the devices in the plan if it succeeded. Read-only, using the same rules as the Horizon what-if.
• Device classes and your own invariants: administrators can now tune Horizon per device class at /admin/horizon-policy: switch a shipped invariant off or change its severity for a tag, organisational unit or environment, and write custom invariants as conditions on reported facts (fact = value, fact = a|b, fact != value; no code, no wildcards). The result drives the timeline, What if and Remediation effect. Saves are admin-only, versioned and audited. A fact a device has not reported stays Unknown.
• AI capability graph: a device's AI page now has a Graph view of what each AI product can reach (shell, files, network, MCP servers, secrets in configuration, ports open to other machines, credential stores) and ranks the dangerous paths, for example an unrestricted shell that can read Azure credentials and reach the network. Built only from what the device already reports; anything it could not tell is listed as unknown, never as safe. The AI page shows a fleet roll-up of devices with High paths.
• Out-of-date Defender flagged: a device whose Defender platform or engine is two or more months old now gets an Updates finding (Low at 2 months, Medium at 4), shown on the Posture page (with a Defender out of date tile and report view, also linked from a Devices chip), the device page and as a Dashboard attention item. A device's page offers Plan an update, a Manual hand-off remediation plan that Highwind verifies when the device reports a Defender version at or above the one you set. Highwind still sends nothing to the device. The age is read from the release month encoded in the version (26070 is 2026-07), so it works offline and in sovereign clouds, but it is an estimate, not a check against Microsoft; set Antimalware platform/engine version at least in the posture baseline for an exact minimum. The newest-in-fleet comparison now starts at two devices instead of five. Fixed: a device that had never been scanned showed a full-scan age of 4294967295 days; it now shows as unknown.
• Last barrier and policy provenance (FleetPolicyProvenanceEnabled): the new Last barrier view (/horizon, and per device under Horizon) shows which dangerous states (untrusted code runs, kernel access, credential theft, data exfiltration) are guarded by only one active barrier. Kernel, persistence and software state now feed the Horizon invariants (set 2026.10.2), and missing evidence stays Unknown. Opted-in devices also report where policy lives (MDM, Group Policy, Configuration Manager), reading key names and counts only, never values. Default off.
• Device Trust: every device gets one explained score from eight categories: Identity, Execution, Kernel, Configuration, Network, AI/Agent, Data Protection and Persistence Risk. Each category is 100 minus listed deductions, and every deduction shows its finding, evidence, reason, severity and fix, at Posture > Device trust and in each device's Device trust panel. The scoring is fixed rules, not a model. A category a device has not reported is left out rather than counted as good or bad, and the overall score is held to 40 above the weakest area so one failing category cannot be averaged away. Needs no policy; it is built from reports the service already holds.
• Security timeline: Posture > Timeline merges security-setting, persistence, kernel, software and AI changes (and, for administrators, audited activity) into one newest-first story. Select a device, user, binary, certificate, driver, process, AI agent or MCP server to see every event that involves it. Needs no policy. Highwind does not collect process launches or network connections, so the timeline shows what appeared and changed, not what ran.
• Remediation workflow: Posture > Remediation turns a finding into a plan with a dry run, approval (a second administrator for high-impact plans), a canary wave, verification from device reports and rollback, all audited. In this release Highwind sends nothing to devices: you make the change in your own tool, record it, and Highwind verifies it from the next report.
• Rule preference per tenant: App Control → Settings orders the rule kinds; recommendations and file plans follow it. Folder rules stay opt-in with a risk acceptance.
• App Control policy packages (Policy package generation switch, mode Generate): build a supplemental policy for a base, or an audit-mode deny base, from approved rules; validated, versioned and hashed; approved by someone other than the builder; then download the XML and manifest (checked by SHA-256) and compile it with ConvertFrom-CIPolicy. Highwind deploys nothing.
• Clearer Applications wording: Blocked now and Would be blocked (audit).
• Expected policies: must NOT be present. Each policy now has one Requirement choice (Not checked, Must be active, Must be active + enforcing, Must be present, Must NOT be present). A device still carrying a retired or competing policy is Drifted with the finding Policy that must not be present, and raises an alert. Cleaner, compact editor; the sets table shows must-have and must-not chips.
• App Control deployment plans (Deployment tracking switch, modes Deploy to lab / Deploy by rings): plan an approved package in rings (default Lab, IT pilot, Pre-production, Broad production; editable). Highwind never deploys: you deploy each ring in Intune (recommended) or another channel and record it; Highwind measures the ring from device reports (policy version converged, new blocks, affected devices, critical applications, observation window) and a ring passes only when its gate is met. Plan and ring approvals by Rule approvers other than the creator; validation by someone other than the last deployer; rollback names the previous version. New permission Deployment operator. Migration ManagementRound14; no agent change.
• App Control production lifecycle: Recertify approval (Board member, up to two years); Recertification due and Exception expiring alerts ahead of time; a Needs attention list on the App Control overview that says what is waiting and who acts; an audited decision register CSV for auditors; file scan answers pruned after 180 days. No schema change.
• Fix: scanning the files of an MSI-installed application (for example Highwind itself) found nothing when the uninstall entry had no install folder; the agent now asks Windows Installer for the product’s files, and the Highwind MSI records its install folder.
• Clearer rule plan: What to allow now says plainly that every suggested rule is needed together (not alternatives), groups signed files by signer with the products listed inside each rule, and moves the folder rule and the preference explanation into collapsed sections.
• Easier portal for everyone: resizable table columns (drag the heading edge or use the arrow keys; widths remembered per page, double-click to reset), a framed table style with shaded headers and alternating rows, a one-line description on the dashboard and device pages, hover explanations on technical column headings, and plain names: Checking in, Device health, Trust; App Control states Up to date, Different from expected, Catching up, No recent report, Not judged, Could not read policies; Flapping for oscillating devices. API values and URL filters are unchanged.
• Fixes: table rows that did not line up on the Applications page; a page not found after some buttons (“opaque-redirect”); events filed under the wrong application record (now tied to the application by its install folder and programs, so an application could no longer show no events while its device logged thousands).
• Compare New-CIPolicy levels: each scanned application shows what New-CIPolicy -Level … -Fallback … would write at every level (Hash, FilePath, FileName, LeafCertificate, FilePublisher, SignedVersion, Publisher, PcaCertificate): rules, files allowed by the level and by each fallback, whether it is too broad, what it trusts, what happens on an update, and the exact command to cross-check on a device. Worked out from the existing scan: no PowerShell runs on devices. The level order is set under Admin → App Control; the Board’s rule options name their closest level. Fix: after an approval, step 2 Pick the rule now appears (it said “Not needed for this decision”). Migration ManagementRound15.
• Rules built like New-CIPolicy (Level + fallbacks): the Board’s first rule option is now the rule set New-CIPolicy -Level X -Fallback Y,Z would write with your level order: each file gets the first level that fits, so signed files get signer rules and only what is left falls back to file paths or hashes. New default order Publisher, FilePublisher, SignedVersion, PcaCertificate, FilePath, Hash, FileName (up to 7 levels, change it under Admin → App Control). New rule kinds Publisher, Issuing CA (PcaCertificate), Publisher + version (SignedVersion), Signing certificate (LeafCertificate) and File path; packages write them exactly as New-CIPolicy does. Rules now use both the file scan and the event logs: installed files that have not run yet are included. The option lists each level it uses.
• SHA-1 hashes too: file scans now also record the Authenticode SHA-1, and hash rules are written with both the SHA-256 and SHA-1 Authenticode hash, as New-CIPolicy does. Needs this release’s agent; page hashes are not written yet.
• One simple plan on the Board: Pick the rule now offers plans that follow your rule order, the same order the application’s Files and rules page shows. Step 1 (for example Signer + product) allows every file it can; only the files left over go to the next rule type. Each plan is a short table (rule type, what it means, files, rules, which files). The recommended plan follows your order; the others keep step 1 and let you choose how the files left over are allowed (exact path, hash or file attributes). New-CIPolicy and single-rule options moved under Other ways. The Board says when the files were scanned after the options were built and offers Update the options. The Files page now allows unsigned files in a protected folder by exact path (a folder-wide rule stays an option that needs a risk acceptance). Fixes: radio buttons line up with their text; longer help text uses the page width. The Enterprise Setup web pages (setup, deploy, Azure, ADMX, fleet, Power BI) use the whole window width.
• Fix: choosing a rule with Use this rule left it Proposed – waiting for a rule approver although you may approve it: the approval waited for an impact simulation that was never run. It is now simulated and approved in the same step, and the reason is shown if it cannot be.
• Portal: light, dark or system theme (top right, or your name → Account); tables use the full window width; Last inventory beside Last heartbeat, highlighted when they differ.
• Fix: tag baselines layer on the default. A device matching a tag baseline is checked on Default + tag: every default setting, plus the tag’s settings, and where both set the same setting the tag’s value wins, so each setting is checked once (tag before organisational unit before environment). Before, a device could be checked against both values of one setting and show “Differs from baseline” although it matched its tag.
• Board rule builder: step 2 is now Build the rule. Pick the main rule (for example File publisher for the 102 signed files) and the rule for the files left over (file path or hash); a bar shows when every file is allowed (100%). Each step says in plain words whether it could let in other software (Only this app, Some other software, Lots of other software). Open the file list to give one file another rule, and Preview the policy to see the XML the package will contain, with the matching New-CIPolicy command to compare on a device. Use this rule saves it (and approves it when you may). The earlier plans stay under Or pick a ready-made option. No schema or agent change.
• Delete a package and start the application again: a package page has Delete this package (open when it has errors). Tick the applications to send back to Build the rule: their approved rule is retired so the next package no longer includes it (applications named in an error are ticked for you). Approved packages need a policy approver; packages in a deployment plan are kept. Also: clearer rule builder drop-downs (no clipped text, A/B cards) and the files you changed are highlighted.
• Scripts and installers get a usable hash: scripts (.js, .vbs, .wsf, .ps1) and installers (.msi) no longer show hash not available, and a package no longer refuses them as "plain SHA-256". The agent now reports the hash Windows checks for these files (scans from older agents work too). The rule builder explains that scripts can only be allowed by hash or signature, and leaves out batch files (.bat, .cmd: App Control does not check them) and .hta files (always blocked under a policy). Package download always saves as .xml; the deny-policy option is now called Enable Audit Mode. Agent change: install the new MSI and run Scan files again.
• One policy per application, merge when you want: Packages now lists each application as its own allow policy, with Build/Rebuild, View and Download XML on the row and a plain status (Ready to build, Waiting for approval, Ready to download, Out of date: rebuild, Has errors). One application can be updated or removed without touching the others. Tick two or more applications of the same base policy and Merge ticked into one policy to keep the number of policies on devices low (Windows before 11 24H2 runs at most 32). A package page shows what it holds. The Board’s Open Packages link highlights the application. Older whole-base packages stay listed. Migration ManagementRound16; no agent change.
• Scan first, then decide: an application page now opens with its key facts as cards and two steps: 1 Scan the files (search for a device to scan from, or leave it empty and Highwind picks; who asked, when, and which device answered are shown and update live) and 2 Decide on the Board (Open review is recommended once a scan exists; without one it says why the Board cannot build a rule yet). Identity details moved into a collapsed section. Packages: each base policy is a clear heading with its policies below. Download XML saves as Application name_PolicyID.xml, and hash rules are named after their file (UpgradeApplicationHost.js Hash Sha256), as New-CIPolicy names them. No schema or agent change.
• Cleaner baselines: Security posture → Baseline compliance offers All devices, Default (no tag) and one Default + tag view per tag baseline. In a tag view the tag’s settings come first (marked as winning over Default, with the default’s value beside them when it differs), then the default settings the tag does not set. Baseline differences moved out of Top issues and All issues into Baseline compliance (the Overview links to it). Admin → Baselines: every category table uses the same column widths, so the columns line up down the page, in framed sections with compact drop-downs. No schema or agent change.
• Cleaner, faster portal: the Dashboard opens with three cards (Fleet health with a status bar, Security posture with 7-day change, App Control compliance) and one Needs attention list that says what is wrong, how many, and where to fix it. App Control’s overview shows a compliance bar, the same Needs attention list and an Application lifecycle funnel (applications seen → not reviewed → in review → approved → waiting for a rule → packages to approve → rolling out, each a link); its tabs are grouped into Monitor and Govern. Select your name for Appearance (match system, light, dark) and Density (compact, normal, comfortable), remembered per browser. Tables sort when you select a column heading, long tables keep their headings in view, and Devices has one-click filters (Awaiting approval, Unhealthy, Not enrolled, Longest silent) with removable filter chips. A device page shows its name, status and what needs attention at the top. No API, schema or agent change.
• Who uses each device, and faster navigation: a Last user column on the Dashboard and Devices (and on the device page); Devices search matches a device name or a user. The agent reports the last signed-in account with its compliance answer; set the new policy FleetReportLastLoggedOnUser to 0 to stop it (the stored value is then cleared). Press Ctrl+K (or Search at the top) to jump to any page or search devices, users and applications; save Devices filters as named views in your browser. The Dashboard posture card shows a clean / lower findings / high finding / no answer bar. Policy sets show a compliance bar per set, an application page shows its journey (found → scanned → decided → rule → package → deployed), and App Control Needs attention lists rollouts with no progress for 7 days and recent rollbacks. Admin, Posture and Queries pages share one header with a breadcrumb. Needs the new API (migration ManagementRound17), portal and agent MSI.
• Access page: search Entra users and security groups by name and pick one (needs Graph User.ReadBasic.All and GroupMember.Read.All on the API’s identity; otherwise paste the object ID). Devices are a tick list of tags. Picking a role ticks every permission it gives, grouped as Devices, Administration and App Control; changing a tick makes it Custom.
• Check my permissions: the account menu opens a list of every permission, whether you have it, and where (every device, which tags, or tenant-wide).
• Devices with several tags: a device is always checked on the default plus one tag, and tags are never mixed. On Baseline compliance a device tagged DEV and US-East appears under both Default + DEV and Default + US-East, checked once for each. Picking a tag on Posture checks its devices on the default plus that tag. The Dashboard Needs attention columns now line up on every row.
• Highwind Fleet license: the Fleet portal and management API now need a signed license file (.hwlic) from Highwind, imported in Admin → License (check the file, compare its SHA-256, import). It is verified offline on your server: no internet, phone-home or hardware fingerprint. The page shows the customer, features, device limit, binding, expiry and history, and offers Check again and a support summary. A banner warns 30 days before expiry; an expired license makes the portal read-only; with no license only Admin → License opens. Devices are never affected, and the free desktop client never needs a license. After upgrading, import your license (migration ManagementRound19). Details →
• Personal and workplace devices: administrators can mint an enrollment secret that lets a device outside the domain allowlist or Entra tenant enrol, including one joined to a different Entra tenant. It always needs approval, is never graded domain-verified and is audited. Device identity gained a device-name wildcard approval rule, a Certificate authorities page for registering an on-premises CA, and tooltips on the device list columns. A device with no Entra token or app registration can use the same secret as its credential: the agent exchanges it for a per-device certificate and registers with signed requests.
• New license terms: from 3.7.0 the desktop client, Fleet agent and ADMX templates are free to use (including commercially and in government) under the Highwind Client License; the Fleet management API and portal are licensed under the Highwind Fleet License. Releases before 3.7.0 remain available under the MIT License.
• SharePoint decisions upload: connecting to a new or different list (or changing the upload level) now re-checks every local application, so a freshly created list is filled instead of staying empty. Applications are uploaded even when the grid was loaded from the local ledger without running the query (anything seen in the last 31 days, or with a decision). Failed items now show the reason from SharePoint, the status turns red, and everything is written to %LOCALAPPDATA%\Highwind\Logs\sharepoint-decisions.log. Highwind no longer hides its bookkeeping columns (DecisionKey, TenantId, SchemaVersion, DecisionScope): Microsoft Graph refuses to write hidden columns (“Field 'DecisionKey' is not recognized”). Lists created by earlier builds could be missing these columns while still validating as ready; validation now reports them, and Create or Validate List adds or unhides them.

Set up and test central management →

Enterprise documentation reorganized

The Enterprise pages now share one left-hand navigation and open with a short overview. New pages cover Client reporting, the Security model and Troubleshooting.

The long central management page is split into Deploy and verify, Devices, posture and access, App Control and Scale and network protection. Text diagrams are replaced with images. Old links to sections of the central management page still work from this site.

👤 For Administrators

• Validate in lab: test a change on a few devices tagged Lab or Test and read the result in the portal. You make the change yourself; Highwind watches and compares health before and after. The What if page now has one button, Check this change, and lists what could break and what devices reported in the last 24 hours. Not yet tested on real devices.
• MSI: Highwind-3.7.0.msi. Install directory, detection key and policy key are unchanged.
• New optional install property: INSTALLFLEETAGENT=1 installs the HighwindFleetAgent service. It is kept across upgrades once installed. Details →
• New policy values under HKLM\SOFTWARE\Policies\Highwind:
  • Six App Control page visibility values (VisibilityAppControlBlockPage, …AllowPage, …ReadinessPage, …ImpactPage, …RuleRecommendationsPage, …LocalPoliciesPage) — default administrators only.
  • SharePointDecisionStoreEnabled — default off.
  • EnableDemoMode — default off; never set on production devices.
  • The Fleet* values that configure the Fleet Agent — full list, including FleetCustomChecksEnabled (default off) for custom checks.
  • The existing DeviceTag, OrgUnit and Environment tagging values are now also reported by the Fleet Agent for device groups and operator scopes.
• ADMX: updated. Import the new templates to get the Fleet Agent category, the App Control visibility pages and the SharePoint setting. The template no longer declares an unused dependency on the Windows namespace, so it now imports into Intune (Import ADMX) without the NamespaceMissing:Microsoft.Policies.Windows error. Download and Intune steps →
• New per-user files: pinned prompts (%LOCALAPPDATA%\Highwind\pinned-prompts.json), the Security Watch state and inbox (%APPDATA%\Highwind\highwind-watch*.json), window and grid layout, and the SharePoint profile.
• Server components (Management API and Portal) ship as separate packages and are only needed if you run Fleet central management.
• Upgrade behavior: drop-in over 3.6.0 and 3.5.0. Settings, decisions and history are preserved.

Version 3.6.0 — In development

A maintenance release with one job: move Highwind onto .NET 10 before .NET 8 stops receiving security updates. There are no new features and no behaviour changes. If everything has gone to plan, the only thing you will notice is that the download is slightly larger.

🔄 Moved to .NET 10

• Nothing to install. Because the runtime is bundled, there is no prerequisite to deploy and no ordering problem on your side. Machines do not need the .NET 10 Desktop Runtime present, and having it — or not having it — changes nothing.
• The package grows a little. The .NET 10 runtime is slightly larger than .NET 8, so the MSI and the portable ZIP both gain a few megabytes. Worth knowing if you stage installers over constrained links or pin package sizes in a deployment tool.
• Everything else is unchanged. Same install directory, same registry keys, same policy key, same scheduled task names, same ADMX templates. No configuration is migrated because nothing moved. Detection rules and management scripts written for 3.5.0 continue to match.
• Windows requirements are unchanged. Windows 10 version 1809 or later, or Windows 11, exactly as before.

🔧 The PowerShell engine is back in step

Highwind pins the PowerShell SDK so its collectors behave identically everywhere, rather than inheriting whatever PowerShell happens to be on the machine. That pin had drifted: the SDK and the automation engine underneath it were held at different versions, which .NET 8 tolerated silently and .NET 10 refuses to build at all.

The two halves are now kept together by construction instead of by hand, so they cannot drift apart again. This is invisible in normal use, but it is the one change in this release with any real chance of affecting collector behaviour, and it is the thing worth watching if a collector reports something unexpected after upgrading.

🧹 Small correctness fixes found on the way

• Two streaming reads no longer block. The firewall log tail and the AI response stream each performed a hidden synchronous read while awaiting data. Neither was visible as a hang, but both held a thread they had no need to hold.
• Authenticode signature reads are unchanged and deliberate. The newer runtime flags the certificate-loading API used to read a publisher out of a signed binary. The replacement Microsoft offers does not do that job, so the existing call is retained on purpose and documented as such — signature verification behaves exactly as it did in 3.5.0.

👤 For Administrators

• MSI: Highwind-3.6.0.msi
• Install directory: C:\Program Files\Highwind — unchanged
• Detection registry key: HKLM\SOFTWARE\Highwind\Version = 3.6.0
• Policy key: HKLM\SOFTWARE\Policies\Highwind — unchanged, no migration required
• Scheduled tasks: unchanged
• Silent install: msiexec /i Highwind-3.6.0.msi /qn
• Upgrade behavior: drop-in over 3.5.0. Settings, the ASR exclusion ledger and your collected settings history are all preserved.
• ADMX: no change. The templates from 3.5.0 remain correct.
• Runtime: .NET 10, bundled. Nothing to deploy separately.

Version 3.5.0 — Latest

Four things happen in this release. The tool is renamed from MDE Toolkit to Highwind; Highwind AI becomes the fastest way to find out what is actually going on with a machine — including, for the first time, what has changed on it; remote targeting is repaired — a much bigger statement than it sounds, because until now a remote scan could quietly report the local machine instead; and App Control gains the tooling to take a rollout from audit mode to an enforceable policy.

🏷️ Renamed to Highwind

Same project, same maintainer, same licence. The old name described a Microsoft product rather than this tool, and the tool is not a Microsoft product — it is an independent project that reads Microsoft's telemetry and tells you what it says. A name that implied otherwise was doing nobody any favours, least of all the people who had to explain it in a change ticket.

• Your existing configuration is migrated on upgrade. The installer copies every value from HKLM\SOFTWARE\Policies\MDE-Toolkit to HKLM\SOFTWARE\Policies\Highwind before it seeds any defaults, and it never overwrites a value that is already set. GPO and Intune settings survive an in-place upgrade with no action required.
• The application also falls back at read time. Any setting missing from the Highwind key is read from the old key instead. That covers the portable ZIP, which never runs an installer and so never gets the migration.
• Per-user files are carried across on first launch. Cached sign-in records, export and Advanced Hunting preferences and the AI user secret are copied from the old per-user folders into the new ones. This is done by the application rather than the installer because those files are DPAPI-protected under each user, and the installer runs as SYSTEM. Earlier builds were not consistent about the folder name — several were in use at once — so every one of them is checked.
• Machine data moves too. The ASR exclusion ledger, the collector cache and stored reports are copied from %ProgramData%\MDE-Toolkit into %ProgramData%\Highwind. Without this the Exclusions tab would come up empty on an upgraded machine while the permanent exclusions it created were still live in Defender — the tool would no longer know it owned them, and the record of who excluded what would be stranded in a folder nothing reads.
• The expiry sweep changes hands cleanly. The upgrade retires the old \MDE Toolkit\ASR Exclusion Sweep task before handing the ledger over, because two SYSTEM sweeps reverting the same rule and path from two copies of the ledger is exactly the overlapping-exclusion corruption fixed in 3.3.2. Any temporary exclusion still running is then re-adopted at startup, so nothing outlives its expiry during the handover.
• Nothing is deleted. The old policy key is left exactly where it is. If you need to roll back to 3.4.0, its configuration is still there and still authoritative for that build.

The reason this is handled so carefully is that the failure mode is invisible. A renamed policy key that nothing reads does not produce an error — the application starts, the UI looks healthy, and the fleet quietly runs with no upload endpoint, no tenant and default guardrails. That is worse than a crash, because nobody investigates it.

🧠 Highwind AI

Ask a question about a machine in plain English and get an answer, instead of reading six pages of settings and working out for yourself which of them matter. “Is this machine protected?”, “why is Defender not updating?”, “what changed last week?” — Highwind reads the machine, works out which parts of it are relevant to what you asked, and explains what it found and what to do about it.

Two things make the answers worth trusting. Every fact comes from the machine itself and is shown with its source, so you can check it rather than take it on faith. And where Highwind cannot read something, it says so — it will not fill a gap with a confident guess, because a wrong answer that looks right is worse than no answer at all.

🕒 It remembers what your settings used to be

The biggest addition in this release, and the one with no equivalent elsewhere. Highwind now takes a quiet snapshot of the machine’s security configuration every few hours and keeps a rolling 30 days of history. That turns a question nobody could previously answer into an ordinary one:

“What has changed on this machine in the last 30 days?”

• You get told what moved, when, and whether it left you worse off. “Controlled folder access was switched off on 9 September” — with a plain statement that this left the machine less protected than it was.
• It covers settings that Windows never records. Defender logs some of its own configuration changes, but the firewall profiles, App Control, Device Guard, BitLocker, Remote Desktop and the PowerShell policy emit nothing at all. Comparing snapshots catches all of them, and it does not depend on an event log that may have already wrapped.
• It does not matter who was signed in. Snapshots are taken by the system itself, so a change made overnight, or by someone else, or by a policy push, is captured the same way.
• Ask about any period. The last 24 hours, the last five days, the past two weeks — the question is answered over the period you actually asked about. If Highwind has less history than that, it tells you, rather than letting a short record look like a quiet one.

🔍 And it explains the setting, not just the change

Being told a value moved is only half an answer. Each reported change now comes with the part you would otherwise go and look up: what the setting actually does, where it is configured in Intune and in Group Policy, the registry location, what the numbers mean, and the handful of things that realistically cause it to move — most likely first.

Highwind then checks the machine live and tells you whether anything is enforcing that value right now. That is the difference between “go and check Intune or Group Policy” and “nothing is enforcing this here, so look at who has local administrator rights.”

Where the change cannot be traced to a specific policy — which is usually, once the logs have rolled — it says so plainly and points at the places evidence may still survive, rather than inventing a culprit.

📚 Research, with its sources shown

For the questions that are about Defender rather than about your machine — what a setting means, why a feature behaves the way it does — Highwind draws on a built-in knowledge base, and, if you allow it, looks things up at Microsoft Learn and other public sources. Answers carry links, so you can read the original. Your organisation can turn outside lookups off entirely by policy.

💻 Works on a machine with no internet, and on machines that are not yours

• No AI service required. Highwind AI answers using a local engine, so it works on an isolated machine with nothing configured and nothing outbound. Nothing about your machine is sent anywhere. Connect your own AI endpoint if you want richer wording — the facts come from the machine either way.
• Remote machines get real answers. Point Highwind at another machine and the answers are about that machine — including its settings history. If it cannot be reached, it tells you which machine and why, instead of quietly describing the one you are sitting at.

📄 Reports you can hand to someone else

Highwind AI can write the whole thing up as a report, and you choose what it should concentrate on: a security review, or a troubleshooting investigation. The same machine, the same evidence, but the emphasis, ordering and recommendations shift to suit the reader — a summary for management is not the same document as a working list for whoever has to fix it.

🐜 The typing hang

The original bug report, and the one that started everything else in this release. Every keystroke in the target field triggered a synchronous UNC probe of the typed value. Typing a machine name meant firing a network round trip at every prefix of it, on the UI thread, so the window locked up for as long as the network took to give up on names that were never going to resolve.

The probe is gone from the keystroke path entirely. Reachability is established when you actually target the machine, where waiting for the network is something you asked for.

📡 Remote targeting actually works now

Investigating this exposed something considerably worse than a hang. Credentials were not reaching most of the remote data paths, and the code that needed them fell back to reading the local machine instead of failing.

• Credentials now reach remote registry, UNC, event log and WMI. Previously they were honoured on some paths and silently dropped on others, which is why a remote target could half-work and look convincing.
• Timeouts everywhere. Every remote call is now bounded. An unreachable host returns an answer instead of holding the operation open indefinitely.

⚠️ Silently-local data is gone

This is the headline correctness fix. When a remote collection could not complete, several subsystems fell through to the local machine and presented the result as though it came from the target. A remote assessment could therefore describe the analyst's own workstation while naming somebody else's device at the top of the report.

That is not a cosmetic bug. It produces a confident, specific, well-formatted answer about the wrong computer, and there is nothing in the output to suggest you should not believe it. Every one of the following now reports the target or reports nothing:

• Device Control
• Firewall enrichment
• Support bundle
• ASR rules and exclusions
• Live event tailing
• Endpoint Posture Score
• STIG compliance

🔒 Wrong-machine writes are blocked

The mirror image of the previous problem, and the more dangerous half. Several actions could write locally while a remote target was selected — so an operator intending to change a remote device would instead modify their own.

Device Control policy edits, ASR exclusion creation, Quick Actions and support bundle generation are all now refused rather than silently redirected when the write cannot be performed against the selected target.

👁️ Uncertainty is visible

The through-line of this release: where the tool does not know something, it now says so instead of producing a verdict it cannot support.

• Per-page data-source banners. Every page states which machine its data came from, so “local” and “remote” are never something you have to infer.
• “Not determined” replaces invented verdicts. A check that could not run reads as not determined rather than defaulting to pass or fail. A fabricated pass is a security finding you never see; a fabricated fail wastes a day.
• Per-section collection results. Partial collections report which sections succeeded and which did not, instead of presenting an incomplete picture as a complete one.

🛠️ CLI / GUI parity and batch reporting

The command line and the interface had drifted apart and could produce different results from the same inputs. They now run the same code path. Batch reporting, previously CLI-only, is available in the GUI on that same shared path — so a report generated either way is the same report.

🔧 PsExec

PsExec-based remote provisioning was broken and is repaired. Fetching it is now an explicit, optional, signed download rather than an assumption, and it remains disabled entirely where DisablePsExecDownload is set — a tool Defender flags as HackTool:Win32/PsExec should never arrive on a machine without someone choosing it.

🔐 App Control — building a policy from Advanced Hunting

The largest body of work in this release. The goal is narrow and specific: make it realistic for an administrator to go from “App Control is deployed in audit mode” to “here is the policy I am prepared to enforce” — the step most rollouts stall on.

• Fleet Impact with a Group by level. Aggregates events server-side so one row is one thing you would write a rule for, rather than one raw event. Five levels — publisher, publisher + product, file identity, file + location, hash — matching the rule you intend to author. Per-user install paths are normalised to \Users\*\, so one application stops producing one row per profile.
• Switching view or Group by no longer re-runs the query. Results are regrouped from data already collected. Grouping only runs one way, though: you can always go coarser, but detail discarded server-side cannot be rebuilt — asking for hashes after collecting at publisher prompts a re-run rather than showing something wrong.
• A Decisions workbench. Record Allow / Block / Investigate per application, with owner, rationale and a reference. The ledger can be exported, imported and synced against a file on a share, so several administrators can work the same list. Merges are last-decision-wins and report conflicts rather than hiding them.
• Rule precedence on the main toolbar. It decides the recommended rule on every row, so it now sits beside the results instead of inside the Policies drawer. A badge marks an order that differs from Microsoft’s recommended default. See Rule precedence.
• Graduated scrutiny instead of a risk flag. A Microsoft-signed kernel driver is not “risky” simply because it loads in the kernel. Rows are now rated on how much review they warrant, which stops the signal being drowned by things that never needed looking at.
• Duplicate path forms are collapsed. Code Integrity reports the same event twice, once with a \\?\ prefix. That is not cosmetic — a FilePath rule containing \\?\ is invalid — so the pair is merged and counted once.
• Export reflects what you are looking at. CSV export moved to the main page and now honours the active filters and includes the comparison columns when Compare has run. A companion -context.txt records the query window, filters and policies compared against, so the file can be handed on without explanation.

📊 Very large tenants

Advanced Hunting has a 30-day retention, a complexity limit, a response-size cap and a rate limit. On a six-figure device estate all four bite, and the previous behaviour was to quietly return less data rather than say so.

• The 30-day window is collected as shards. A shard that overflows is split repeatedly down to a 30-minute floor, and transient throttling is retried per shard rather than restarting the scan.
• Truncation is now reported, not absorbed. A per-shard row cap could succeed while dropping rows, and the adaptive split only reacted to outright errors. Saturation is now detected and surfaced — which matters, because the dropped rows are the low-reach long tail that is precisely what is still missing from your policy.
• Device counts are never summed across shards. Shard windows are disjoint in time, not in devices, so summing counted one machine running one application daily as thirty machines. Counts are now a union where exact, and a stated lower bound otherwise.

📈 Renamed: Endpoint Posture Score

The old name sat too close to Microsoft Secure Score, an unrelated Microsoft product. This score is calculated locally by Highwind from local data and has never had any relationship to it. The score, weighting and remediation guidance are unchanged — only the label.

📕 App Control documentation

Numbered walkthroughs in the in-app knowledge base, and a fuller guide at App Control. The guided tour now loads policies before running the query, so results come back already compared.

👤 For Administrators

• MSI: Highwind-3.5.0.msi (was MDE-Toolkit-3.4.0.msi)
• Install directory: C:\Program Files\Highwind (was C:\Program Files\MDE-Toolkit)
• Detection registry key: HKLM\SOFTWARE\Highwind\Version = 3.5.0 (was HKLM\SOFTWARE\MDE-Toolkit\Version)
• Policy key: HKLM\SOFTWARE\Policies\Highwind (was HKLM\SOFTWARE\Policies\MDE-Toolkit) — migrated automatically on upgrade
• Scheduled tasks: Highwind Collect and Highwind Upload, with the sweep task under \Highwind\ (were MDE Toolkit Collect / MDE Toolkit Upload under \MDE Toolkit\)
• Settings history collection is on by default. Highwind Collect runs as SYSTEM every eight hours and writes a configuration snapshot to %ProgramData%\Highwind, keeping a rolling 30 days. This is what the settings history and change tracking read. It stays on the machine — nothing is uploaded unless you separately configure an upload endpoint. Set EnableBackgroundCollector to 0 in the policy key to turn it off.
• Per-user data: moves to %LOCALAPPDATA%\Highwind and %APPDATA%\Highwind, and is copied across on first launch. Cached sign-ins, export preferences, Advanced Hunting preferences and the AI user secret all carry over — nobody is asked to sign in again.
• Machine data: moves to %ProgramData%\Highwind, migrated by the installer. Covers the ASR exclusion ledger, the collector cache and stored reports. The old directory is left in place.
• Sweep task: \Highwind\ASR Exclusion Sweep replaces \MDE Toolkit\ASR Exclusion Sweep, which the upgrade unregisters.
• Silent install: msiexec /i Highwind-3.5.0.msi /qn
• Upgrade behavior: drop-in over any 3.x build. The major upgrade removes the old product, its install directory and its scheduled tasks before installing this one.
• ADMX: re-import the updated templates. They target the new policy key.

Download 3.5.0 from GitHub Enterprise deployment

Version 3.4.0

The headline is supply chain: release artifacts are now digitally signed, so you can verify what you downloaded before you deploy it to a fleet. Alongside that, a Smart App Control reporting bug is fixed that had been wrong in the dangerous direction, EDR onboarding moves onto the Overview page, and the application icon changes.

This release shipped under the tool’s former name, MDE Toolkit. It was renamed to Highwind in 3.5.0.

🔏 Signed releases

Every release artifact is signed with Azure Artifact Signing and RFC‑3161 timestamped. Until now the toolkit shipped as an unsigned MSI — an installer that requests elevation and reads your Defender configuration, with no way for you to confirm it was the file that left the build.

• The binaries are signed, not just the installer. Signing is applied to the application assemblies before the MSI is packaged, and again to the finished MSI. Signing only the outer package is common and misleading — it leaves unsigned code inside a signed wrapper, which any organisation that unpacks the MSI will notice.
• The portable ZIP is covered too. It is produced after the signing step, so the executables inside it carry the same signature.
• The build fails if signing does not happen. A verification step checks every artifact and rejects anything that is not validly signed and timestamped. A silently skipped signing step would otherwise produce an unsigned release that looked perfectly successful.

Timestamping matters more than usual here. Azure Artifact Signing issues short‑lived certificates by design; the RFC‑3161 countersignature is what keeps the signature valid after that certificate expires, rather than the download turning untrusted a few days later.

Verify before you deploy:

Get-AuthenticodeSignature .\MDE-Toolkit-3.4.0.msi |
    Format-List Status, SignerCertificate, TimeStamperCertificate

Status should read Valid. A signed package also means SmartScreen has something to build reputation against, and that you can write WDAC or AppLocker publisher rules for the toolkit instead of hash rules that break on every update.

🐛 Smart App Control was reported incorrectly — in the dangerous direction

Two independent defects, both fixed. The second is the one worth reading.

• The WMI value was never read at all. MSFT_MpComputerStatus.SmartAppControlState is a string (On / Off / Eval), despite the name. The code ran it through int.TryParse, which always failed, so the assignment never executed and Smart App Control was silently left unset on the WMI path. The background collector read the same property correctly as a string, so a single machine could report one thing in the fleet table and something else in the interactive UI.
• The registry mapping had two states transposed. VerifiedAndReputablePolicyState uses 1 for enforcement and 2 for evaluation; the toolkit had those the wrong way round. A device in evaluation mode — observing, not blocking — was reported as On, and the Security Score then counted it as fully protected. That is a false sense of safety rather than a cosmetic glitch, and it applied to every code path that fell back to the registry.

Both the WMI and registry paths now produce the same normalised values, so the compliance check and the Security Score can no longer disagree about the same device. Thanks to Eric Lawrence for identifying the registry mapping error.

📡 EDR onboarding on the Overview page

The Intune / Entra Management card gains three rows: EDR Onboarding, Sense Service and MDE Org ID. Previously this required opening a support bundle.

They are deliberately grouped separately from the enrollment rows above them, because MDM management and EDR onboarding are independent. A device can be fully Intune‑enrolled, compliant, and syncing happily while sending Microsoft Defender for Endpoint no telemetry whatsoever. Reading “Enrolled” and concluding “monitored” is exactly the mistake this is meant to prevent.

• “Onboarded” alone is not enough, so it is not shown alone. OnboardingState stays at 1 even when the Sense service is stopped or disabled, so that row on its own would read Onboarded on a machine reporting nothing. A warning badge calls out the onboarded‑but‑not‑running case explicitly.
• The sensor row shows live state and configured start type together. Running (Disabled) will not survive the next reboot; Stopped (Automatic) is not reporting right now. Either value on its own hides a real failure.
• Unknown is reported as unknown. Where the values cannot be read — access denied, or an unreachable remote host — the rows say Unknown rather than asserting “Not onboarded”.

Works against remote targets on the same terms as the rest of the Overview page.

🎨 New application icon

The previous icon was Microsoft Defender’s own product icon. This is an independent open‑source project and is not a Microsoft product, so shipping Microsoft’s product iconography was not appropriate regardless of how recognisable it was.

The replacement is a telemetry trace. The choice is deliberate: a shield claims protection, and the toolkit does not protect anything — it measures, reports, and tells you what to fix. The icon is supplied at every size from 16 to 256 pixels, each rendered natively rather than scaled down, so it stays legible in the taskbar.

📦 Dependencies and project hygiene

• Every NuGet dependency updated, including the authentication libraries (Microsoft.Identity.Client, Azure.Identity).
• The build now fails on a known‑vulnerable package. NuGet auditing runs across direct and transitive dependencies with audit warnings promoted to errors, so a package with a published advisory cannot ship. At time of release the dependency graph has no known vulnerabilities.
• Dependabot monitors NuGet packages and GitHub Actions weekly.
• A security policy and an MIT licence file are now published in the repository, including a private channel for reporting a vulnerability rather than opening a public issue.

👤 For Administrators

• MSI: MDE-Toolkit-3.4.0.msi
• Detection registry key: HKLM\SOFTWARE\MDE-Toolkit\Version = 3.4.0
• Silent install: msiexec /i MDE-Toolkit-3.4.0.msi /qn
• Upgrade behavior: drop-in over any 3.x build. No schema change, no Function App redeploy, and no new or changed registry settings.
• Newly signed: if you previously allow‑listed the toolkit by file hash, publisher rules are now an option and will survive future updates.
• Smart App Control reporting will change on some devices. A machine in evaluation mode that previously reported On will now correctly report Eval, and its Security Score will drop accordingly. The device did not change — the measurement did.

Download 3.4.0 from GitHub Enterprise deployment

Version 3.3.4

A sign-in correctness release. The Highwind Upload scheduled task could open a Microsoft Edge window and ask an unattended machine to authenticate. The failure was counterintuitive enough to be worth writing down: the machines that prompted were the ones joined to the tenant that owns the Function App, and the machines that stayed silent were the ones joined somewhere else entirely.

🐛 Why the joined machines were the ones that prompted

The uploader authenticated with DefaultAzureCredential. That credential knows nothing about Entra device join and cannot use the machine’s primary refresh token — it simply walks a fixed chain of providers and returns the first token it gets. The chain ends at an interactive browser.

• On a machine where an operator had at some point run az login, Connect-AzAccount, or signed in to Visual Studio, the chain found a cached developer token early and returned it silently. No prompt — but also no guarantee the token was for the right tenant, or the right identity.
• On a correctly configured, Entra-joined machine with none of those developer tools signed in, there was nothing in the chain to satisfy. It fell all the way through to the interactive browser and popped Edge, on a schedule, with no one watching.

So device join was not just unhelpful here, it was invisible to the credential. The quieter machine was the misconfigured one.

🔒 The broker now does the sign-in

Scheduled uploads acquire tokens through the Windows broker (WAM), which is the only provider that can redeem the machine’s Entra PRT. On a joined or registered device this is silent and uses the correct identity. The interactive browser is now excluded outright from every code path the background collector uses, and automatic authentication is disabled on the broker itself, so a machine that cannot sign in silently fails and logs a reason instead of rendering a window nobody will ever see.

The previous PreferredAuthMethod = WAM setting never actually used WAM — it constructed a plain interactive browser credential with no broker attached, so it could not do silent SSO either. It now does what its name says.

The fallback path is still available for machines that genuinely rely on a signed-in Azure CLI or Azure PowerShell session, but it is now pinned to the configured TenantId, so a stale sign-in to an unrelated tenant can no longer quietly become the upload identity.

⚙️ New optional setting: AuthClientId

Broker sign-in needs a client application to request the token as. In most deployments the toolkit can work this out on its own, so no configuration change is required to upgrade. It tries, in order:

• AuthClientId, if you set it. An explicitly named registration is used on its own — falling back to a different one would hide a typo and mint tokens under an identity you did not choose.
• The app ID inside FunctionAppAudience. Where a single registration both exposes the API and acts as the public client — the usual Function App setup — this is already authorized for its own scope and simply works.
• The built-in Azure CLI client, which only succeeds if it has been added under Authorized client applications on the API.

Set AuthClientId (REG_SZ, under HKLM\SOFTWARE\Policies\Highwind) when your client and API are separate registrations, or to pin the choice and skip the probe. Whichever registration ends up being used needs public client flows enabled, redirect URI ms-appx-web://microsoft.aad.brokerplugin/<client-id>, and access to the scope named in FunctionAppAudience. When the probe succeeds on a fallback candidate, the log names the client ID that worked so you can pin it.

Recommended for production: set it explicitly. Optional is not the same as advisable — if the probe lands on the built-in Azure CLI client, your Function App is being accessed through Microsoft's app registration. That works, but it means anyone with the Azure CLI installed can request tokens for your API, and Conditional Access cannot be scoped to an application you control. Note that a registration used for blob upload also needs a delegated user_impersonation permission on Azure Storage; the Azure CLI client has that by default, a fresh registration of your own does not.

🔑 Machines outside the tenant: --auth-login

A device that is not Entra joined to the tenant that owns the Function App has no primary refresh token for it, so the broker cannot sign in silently there no matter how AuthClientId is set. Until now such machines worked only because a leftover az login session was quietly supplying every token — an unchosen dependency on a developer tool that would break the moment it expired.

Run once, as the user the upload task runs as:

"C:\Program Files\Highwind\Highwind.exe" --auth-login

This prompts once, acquires consent for every configured upload target, and saves an authentication record to %LOCALAPPDATA%\Highwind\auth-record.json. Scheduled uploads then refresh that account silently. It is the only mode in the toolkit that will ever display a sign-in window. Devices joined to the correct tenant do not need it.

👤 For Administrators

• MSI: Highwind-3.3.4.msi
• Detection registry key: HKLM\SOFTWARE\Highwind\Version = 3.3.4
• Silent install: msiexec /i Highwind-3.3.4.msi /qn
• Upgrade behavior: drop-in over any 3.x build. No schema change, no Function App redeploy, and no new registry settings required to upgrade — though setting AuthClientId is recommended for production.
• Package added: Azure.Identity.Broker, which ships the native msalruntime binaries alongside the application. They are included in the MSI automatically.
• The Highwind Collect task is unchanged. It runs as SYSTEM, which has no interactive Windows account and therefore no PRT, so it continues to use managed identity or Azure CLI and never involved the broker.

Download 3.3.4 from GitHub Enterprise deployment

Version 3.3.3

A telemetry honesty release. Building the fleet dashboards surfaced four fields that the enterprise collector had been reporting without ever measuring. Each was uploaded at its default value on every device, so a report reading them saw false or 0 and had no way to tell that apart from a real result — which is worse than not collecting them at all.

📋 Fields that were never actually collected

• Exploit Protection. ExploitProtectionDepEnabled, ExploitProtectionAslrEnabled and ExploitProtectionCfgEnabled were declared on the snapshot model, never assigned anywhere, and uploaded as false. A fleet dashboard therefore reported “0% enabled” for all three across every device. They are now read from the packed MitigationOptions value under Session Manager\Kernel, decoding the per-mitigation nibble (1 = forced on, 2 = forced off, 0 = OS default). An unset nibble is reported as enabled on 64-bit Windows, because that is the platform default; if the value cannot be read at all, ExploitProtectionStatus becomes Unknown rather than leaving false to masquerade as a measurement.
• Local administrators. LocalAdminCount was never assigned and so was always 0 — impossible, since every Windows install has at least the built-in Administrator. It is now counted with NetLocalGroupGetMembers resolved through the well-known SID S-1-5-32-544, so it does not depend on the display language of the OS. Win32_GroupUser was deliberately not used: it can take tens of seconds on a domain-joined machine, and this collector runs unattended on a schedule. LocalAdminStatus now reflects the actual count rather than only whether LAPS is present.
• App Control enforcement mode. AppControlEnforcementMode was not even declared as a property, so the column was permanently empty. It now reports Enforced, Audit, Deployed or NotConfigured. Deployed is the state worth knowing about: .cip policies are present on disk but Code Integrity is not running them, so they are protecting nothing while looking, in any summary that only asks “is App Control configured”, entirely healthy.

🐛 Scan timestamps were dropped for the freshest devices

Quick and full scan times are derived from Defender’s scan age in days, and the code only recorded a timestamp when that age was greater than zero. A scan that ran today has an age of exactly zero, so the machines that had just scanned — the ones in the best shape — uploaded no scan time at all and were indistinguishable from machines that had never scanned. The test is now >= 0.

👤 For Administrators

• MSI: Highwind-3.3.3.msi
• Detection registry key: HKLM\SOFTWARE\Highwind\Version = 3.3.3
• Silent install: msiexec /i Highwind-3.3.3.msi /qn
• Upgrade behavior: drop-in over any 3.x build. No new permissions, no new registry settings, no schema change.
• The Function App does not need redeploying. It already mapped all four fields — it had been expecting data the collector never sent.

Download 3.3.3 from GitHub Fleet dashboards

Version 3.3.2

A policy-surface cleanup. An audit of every value under HKLM\SOFTWARE\Policies\Highwind found nine settings that were read into the configuration object and then never used, so setting them did nothing at all. Two were worth building; seven were removed.

🔒 Two flags now actually work

• DisableRemoteTarget now pins the toolkit to the local machine. Enforcement sits in the TargetMachine setter rather than on the text box, because that setter is the single choke point every remote-capable service reads from — roughly thirty services branch on it. A non-local value is rejected and coerced back to localhost, so no remote path is reachable even if a future caller sets the target in code. The Target box is also disabled, with a tooltip naming the policy.
• DisableExportButtons now blocks every export path: report PDF/HTML, triage report, scan results, ASR event CSV, Advanced Hunting CSV and XML, supplemental and merged App Control policies, WDAC XML, firewall migration JSON, and investigation details CSV. Blocked attempts show a dialog naming the policy, so the button does not simply appear broken.

Both were documented on this site and in the in-app KB while doing nothing — the same failure mode as ForceReadOnlyMode in 3.3.1. An administrator who set DisableRemoteTarget=1 reasonably believed remote access was off.

🧹 Seven dead settings removed

CollectFirewallRules, CollectWfpFilters, CollectDeviceControl, CollectNetworkInfo, CollectSecurityScore, DisableAiFeatures and DisableAdvancedNetworking are no longer read, no longer seeded by the installer, and are ignored if present. The five Collect* flags promised scope control over data the background collector never gathered. The two Disable* flags duplicated VisibilityAiAnalysisPage and VisibilityNetworkingPage, which are enforced — use those instead.

The six remaining Collect* flags — DefenderStatus, DefenderPolicies, FirewallStatus, AppControl, IntuneEnrollment and DeviceGuard — are genuinely honoured by the collector and are unchanged.

👤 For Administrators

• MSI: Highwind-3.3.2.msi
• Detection registry key: HKLM\SOFTWARE\Highwind\Version = 3.3.2
• Silent install: msiexec /i Highwind-3.3.2.msi /qn
• Seeded defaults drop from 35 to 28, so the policy key now lists only settings that do something.
• Clean up leftovers. The seven removed values are harmless if left behind, but deleting them keeps the key honest: reg delete "HKLM\SOFTWARE\Policies\Highwind" /v CollectFirewallRules /f (and likewise for the other six).

Download 3.3.2 from GitHub All download options

Version 3.3.1

Attack Surface Reduction release. The ASR page becomes a two-page workspace — an overview that finally tells you what mode every rule is in and where that configuration came from, and a new Events page for investigating blocks and tuning them. Admins can create audited, expiring exclusions directly from an event.

🛡️ ASR Overview — one grid, real answers

The overview used to read rule state from a single registry key, which meant it could not see rules configured locally. Two consequences, both fixed:

• Rules set locally are no longer reported as "Not Configured". State is now merged from three sources: Policy Manager\ASRRules (Intune/MDM), the classic Windows Defender Exploit Guard\ASR\Rules GPO key, and Get-MpPreference. On a typical managed device this recovers rules that were previously invisible.
• "Enabled" is now "Block". ASR action 1 specifically means Block; labelling it "Enabled" was ambiguous sitting next to Audit and Warn in the same column. Action 5 ("not configured") is now decoded too.
• New Source column — Intune / GPO, Group Policy, Local, or blank. Locally-set rules are highlighted, because they are real configuration that will not survive a rebuild and is not enforced fleet-wide.
• New GUID column on the main grid, plus the GUID, a plain-English explanation of the source, and any per-rule exclusions in the expandable row details.
• Conflict detection. When policy requests one mode but Defender is enforcing another — a policy that has not applied yet, or a local override — the row is flagged and explained.
• Filters by mode, source and free text. The separate "Not Configured" section is gone; those rules are now rows in the same grid with Mode = Not configured.

📋 ASR Rules > Events — a new sub-page

• Grouped view collapses repeats by rule + process + target, sorted by hit count. Four hundred blocks of one line-of-business binary is one tuning problem, not four hundred incidents.
• Warn bypasses are now visible. Event IDs 1125 and 1126 joined the existing 1121/1122/1129. Event 1126 means the user was warned and ran the content anyway — the rule fired and was defeated — which the overview card never surfaced.
• Locale-safe parsing. Fields come from the structured event XML rather than substring-matching the rendered message, so the page works on non-English installs.
• Filters (search, time range, action, rule, warn-bypasses-only), CSV export, and a generated Advanced Hunting query so you can check whether a block is device-local noise or a fleet-wide pattern before excluding anything.
• Clicking a row on the overview's Recent Events card drills straight through to that event.

🔐 Audited ASR exclusions (Admin Mode)

• Two-step flow. Pick path, scope and duration, supply a required justification, then review the exact Add-MpPreference command and the command that will reverse it before anything is written.
• Per-rule by default (AttackSurfaceReductionRules_RuleSpecificExclusions) rather than the blunt all-rules form, with warnings for overly broad paths and wildcards.
• Temporary exclusions (4h / 24h / 7d / 30d). Defender has no native expiry, so the toolkit tracks them in its own ledger and reverts them via a \Highwind\ASR Exclusion Sweep scheduled task — so they still expire when the app is closed.
• Audit ledger at %ProgramData%\Highwind\asr-exclusions.json recording who, when, why, the exact commands, and expiry. Defender records none of this itself. The directory is ACL'd to SYSTEM and Administrators.
• Policy-managed and Tamper Protection warnings. If Intune/GPO owns ASR, or Tamper Protection is on, the tool says so up front rather than reporting a false success.
• Writes are verified. A zero exit code from Remove-MpPreference is not proof — under Tamper Protection Defender can ignore the change silently. The result is re-checked against Get-MpPreference and reported honestly if it did not stick.
• Reconcile with Defender compares every ledger entry against live state and flags drift in both directions: marked active but missing, or marked reverted but still present.

🐛 Fixes

• Temporary exclusions never expired. Remove-MpPreference matches the ASR rule ID case-sensitively — given the wrong case it exits 0, logs nothing, and removes nothing. The expiry sweep normalised the GUID to lowercase, so every temporary exclusion silently outlived its expiry. Defender keeps whatever case was originally written, so the toolkit now reads the stored ID back and echoes its exact casing. A failed revert is also retried on the next sweep instead of being stranded permanently.
• Exclusion counts were badly under-reported. Get-MpPreference returns rule-specific exclusions |-separated while the registry uses >; only the latter was handled, so a rule with ten excluded paths counted as one.
• Overlapping exclusions no longer corrupt each other. Defender keys exclusions by (rule, path) with no reference count, so two ledger entries shared one Defender entry — an expiring temporary exclusion could silently revoke a permanent one. Expiry is now reference-aware and duplicates are blocked at creation.
• Collection interval mismatch. The code default was 60 minutes while the documentation, the installer seed and the scheduled-task cadence all said 480 (8 hours) — so MSI-installed devices collected every 8 hours but devices without the registry value collected hourly. The code now matches at 480.
• Render-thread crashes are survivable. The application had no global exception handling, so a transient GPU driver or display-topology fault (UCEERR_RENDERTHREADFAILURE) terminated the process mid-investigation. These are now absorbed and logged to %LOCALAPPDATA%\Highwind\diagnostics.log, falling back to software rendering only after repeated failures. Other exceptions are logged but deliberately not suppressed.
• Fixed a crash (NullReferenceException in ListCollectionView.PrepareLocalArray) when loading ASR data.

🔒 Enterprise guardrails for ASR exclusions

New optional policy values under HKLM\SOFTWARE\Policies\Highwind restrict what admins may create. A device with none of them set behaves exactly as before.

• AsrAllowPermanentExclusions (DWORD, default 1) — 0 forces every exclusion to expire.
• AsrAllowTemporaryExclusions (DWORD, default 1) — set both flags to 0 to disable exclusion creation entirely.
• AsrExclusionMaxHours (DWORD, default 0 = uncapped) — hard cap, applied last so it cannot be widened by the list below.
• AsrExclusionDurationsHours (SZ, default 4,24,168,720) — custom duration menu; unparseable entries are ignored and reported rather than silently dropped.
• ForceReadOnlyMode was previously documented but never enforced. It now blocks every exclusion write, creation and removal alike.

Enforcement happens in the apply path, not just the dropdown, so the policy is not merely cosmetic. Temporary-only with a four-hour cap is two values: AsrAllowPermanentExclusions=0 and AsrExclusionMaxHours=4.

👤 For Administrators

• MSI: Highwind-3.3.1.msi
• Detection registry key: HKLM\SOFTWARE\Highwind\Version = 3.3.1
• Silent install: msiexec /i Highwind-3.3.1.msi /qn
• Upgrade behavior: Drop-in over any 3.0.x / 3.1.x / 3.2.x build. No new permissions.
• New page visibility key: VisibilityAsrEventsPage (0 hidden / 1 admin / 2 users / 3 both). Defaults to 1, matching VisibilityAsrDashboardPage. Setting it to 3 gives standard users read-only event triage — the exclusion actions stay hidden regardless, as they are gated on elevation independently.
• Every policy value is now seeded at its default. The MSI writes each setting under HKLM\SOFTWARE\Policies\Highwind at its built-in default, so knobs are visible in regedit and can be edited rather than created. Existing values are never overwritten, and because each seeded value equals the code default, a fresh install behaves identically to a device with no policy key. Values with no meaningful default, and the per-page Visibility*Page values, are deliberately left unseeded.
• Uninstall now cleans up the sweep task. The \Highwind\ASR Exclusion Sweep task is registered at runtime on first use of a temporary exclusion, so uninstall removes it explicitly along with its script. Still-active temporary exclusions are reverted first — a temporary exclusion outliving the tool that promised to expire it would be a silent security hole. Permanent exclusions are left alone and the ledger is preserved as an audit record.

Download 3.3.1 from GitHub All download options

Version 3.2.0

App Control Deep-Dive: six new workflow features and a completely rebuilt ticket-attachment export pipeline. This is the biggest App Control release since 3.1.0.

🔍 Six new App Control features

• Vendor & Product picker for Advanced Hunting. A new FluentWindow popup with a cached publisher / product list scopes your Day-1 hunts without hand-writing KQL. Comes with a new preset that filters events to a chosen publisher/product tuple.
• Audit-mode banner + per-policy Mode / Signed columns. The Overview page now shows Audit vs Enforced at a glance across every loaded WDAC policy. Each row has a Mode pill and a Signed pill derived from the parsed CMS signature — no more guessing whether a .cip is actually signed.
• Impact Scanner (renamed from File Scanner). Load any policy, scan a folder or the entire local machine, and see predicted Allow / Would-Block / Would-Audit outcomes per file. Uses the same comparer as Advanced Hunting so predictions agree across both surfaces. First-run gets a guided tour.
• Fleet Impact toggle in Advanced Hunting. A single click swaps the KQL preset to a unique-binary, device-aggregated query — the "should I deploy this policy?" view. Surfaces would-block %, devices affected, and top blocked vendors in a new summary panel.
• Policy Diff & Merge popup. Compare N loaded policies with per-rule In-All / Only-in-some / Conflict classification, then merge into a single fresh SiPolicy XML with regenerated IDs. Available from both the Advanced Hunting page and the Application Control Policies page.
• PDF ticket reports — completely redesigned. First-page dashboard with a HEALTHY / REVIEW / DEGRADED verdict banner, pillar chips, counter tiles, and severity legend. Table of contents with real page numbers. PDF bookmarks per section, and per-WDAC-policy child bookmarks so a 20-policy machine is navigable from the outline pane. Repeating table headers on multi-page tables. Footer with machine name + timestamp on the left and Page X of Y on the right.

📎 New "Export Report" dialog (replaces "Save PDF for ticket…")

• Format: PDF only, HTML only, or both.
• Sections: 19 checkboxes with All / None shortcuts so you can strip a report down to just Dashboard + Defender + WDAC for a targeted attachment.
• Redaction: machine name, UPN, IP addresses. Applied to both the PDF and HTML output plus the raw JSON snapshot (if requested), so nothing sensitive leaks in a single-file attachment.
• Extras: also emit a raw *.json snapshot next to the report(s) — useful when Tier III wants to re-analyze the collection.
• Post-actions: open when done / reveal in Explorer.
• Preferences persist across launches (%LocalAppData%\Highwind\export-prefs.json).

🌐 HTML export (new)

Single self-contained .html file — no frameworks, no external assets, no CDN references. Same "attach it to a ticket, no assets folder" story as the PDF.

• Sticky toolbar with page-wide search, Expand / Collapse-all, and Print.
• Sticky table of contents that jumps cleanly to sections (proper scroll-margin-top so anchors don't land under the sticky nav).
• Every section is a <details> — WDAC policies collapse by default so a 20-policy machine still opens on one screen.
• Sortable tables — click any column header. Numeric columns are detected and sorted numerically.
• Dark-mode CSS via prefers-color-scheme.
• Print stylesheet strips interactive chrome for clean printouts.

📝 Triage Report HTML modernized

The Triage Report's HTML output now uses the same visual language as the Export Report — dark-mode, sticky TOC, verdict banner, collapsible sections, sortable tables, in-page search. The Save-File dialog now defaults to HTML with Markdown as the second option. Markdown output is unchanged for pasting into ticket bodies (still renders natively in ServiceNow, Azure DevOps, GitHub, Confluence).

🖥️ CLI parity with the GUI

The silent-mode App.xaml.cs handlers are now rewired through the same ExportReportAsync pipeline the GUI uses. Everything the dialog offers is exposed as a flag:

• --export-html <file> — HTML mirror of --export-pdf.
• --format <pdf|html|both> — explicit format selection.
• --include-json — also emit the raw *.json snapshot.
• --redact <list> — comma list: none / all / machine / upn / ip / serial.
• --include-sections <list> — comma list of section names, or all / default / none.

Backwards compatible: --export-pdf alone still produces exactly one PDF at the given path. Batch mode (--machines-file / --export-dir) now honours every new flag; per-host filenames get the appropriate extensions when --format both is used.

🔧 Fixes

• Export Settings window now scrolls when short (was clipping the action bar).
• HTML Policies and Device Control Events tables were rendered empty due to wrong property lookups — now populated correctly.
• HTML navigation links landed one section off — fixed via scroll-margin-top.
• PDF and HTML verdicts could disagree — both now use the same classifier (RTP, Cloud, Tamper, Firewall, Platform / Engine currency).
• Overview Enforced / Audit counters always showed 0 — the getter was reading Status text; it now inspects PolicyObject.Rules for OptionType.EnabledAuditMode.
• Policy Diff popup missing scrollbar / too small — fixed with MinHeight / MinWidth plus a bounded picker.
• Dispatcher-marshal race when browsing folder from a background thread.
• Audit banner text was washed out on some themes — explicit foregrounds per severity.
• CMS-signed pill correctly reflects signed .cip policies.

👤 For Administrators

• MSI: Highwind-3.2.0.msi
• Detection registry key: HKLM\SOFTWARE\Highwind\Version = 3.2.0
• Silent install: msiexec /i Highwind-3.2.0.msi /qn
• Upgrade behavior: Drop-in upgrade from any 3.0.x / 3.1.x. No new permissions, no schema changes, no re-deploy.
• Scheduled tasks: Existing --collect / --upload tasks are unchanged. New export flags are additive.
• Programmatic API: MainViewModel.ExportPdfAsync remains available for existing automation. New code should prefer ExportReportAsync.

⚠️ Known limitations

• The Redact serial number checkbox in the Export dialog is currently a placeholder — no serial-number field exists on the snapshot yet, so ticking it is a no-op. All other redaction toggles are fully functional.

Download 3.2.0 from GitHub All download options

Version 3.1.1

New App Control for Business → Advanced Hunting sub-page that pulls live WDAC events from Microsoft Defender for Endpoint, compares them against your local or custom App Control policies, and recommends the right allow rules to author — with the same -Level / -Fallback precedence semantics as PowerShell New-CIPolicy.

✨ New: App Control for Business — Advanced Hunting

• Direct Advanced Hunting integration. Sign in with MSAL and pull WDAC events (DeviceTvmInfoGathering, audit / enforced blocks, signing-info, script blocks) from the Microsoft Defender for Endpoint Advanced Hunting API. All four sovereign clouds are supported out of the box: Commercial, US Gov GCC, US Gov GCC High, and US Gov DoD — the right endpoint and authority host are picked automatically.
• 21-column KQL projection. The default query mirrors the WDAC-Toolkit guidance exactly: timestamp, device, action type, file name / folder, SHA1 / SHA256 / AuthenticodeHash, issuer + publisher + their TBS hashes, OriginalFileName / ProductName / InternalName / FileDescription / FileVersion, PolicyId / PolicyName, and EtwCorrelationId. Hex values render in Consolas so they line up.
• KQL editor + presets. Built-in editor with one-click presets (All / Blocks only / Audits only / Scripts only / Signing info) that swap the ActionType filter via regex so your custom WHERE clauses survive. Save / load .kql files to share queries with the team.
• Compare against local or custom policies. Load every .cip in C:\Windows\System32\CodeIntegrity\CIPolicies\Active plus SiPolicy.p7b in one click, or browse to a folder of .cip / .p7b / .xml policies (recursive optional). Each event is evaluated as Allowed, Denied (explicit), or Would Still Block across every selected policy. Explicit Deny wins over Allow anywhere in the set, matching how WDAC merges policies at runtime.
• Action plan card. Rolls up the unresolved events into a plain-English plan: how many unique Publisher / FileAttribute / FilePath / Hash rules you’ll need to author, how many Microsoft-signed / kernel / script events were filtered out, and which policies are doing the heavy lifting (per-policy coverage bar).

🔀 Rule precedence (PowerShell -Level / -Fallback)

• All 13 documented file-rule levels are supported. Hash, FileName, FilePath, SignedVersion, Publisher, FilePublisher, LeafCertificate, PcaCertificate, RootCertificate, WHQL, WHQLPublisher, WHQLFilePublisher, and PFN.
• Admin-configurable precedence. The Policies side-drawer has a new Rule precedence expander with a single list of all 13 levels. Drag rows or use ▲ / ▼ to re-rank them; the top entry becomes -Level and the rest become -Fallback in order. A live Consolas-styled preview shows the resulting PowerShell-equivalent command. Order is persisted to %LOCALAPPDATA%\Highwind\advanced-hunting-prefs.json. (Since moved: the precedence editor now lives on the main Advanced Hunting toolbar — see Rule precedence.)
• The recommender walks your order, not a hard-coded one. For each event the comparer picks the first level the Advanced Hunting data actually has enough metadata to satisfy — just like New-CIPolicy. Defaults to Microsoft’s recommended FilePublisher → Publisher → SignedVersion → FileName → Hash → FilePath on first launch.
• Hash > FilePath when both are available. Hash pins exact bytes, so it’s now preferred over FilePath even for admin-only folders. FilePath only wins when the event has no usable hash at all.

🔐 Smarter, safer rule generation

• Dual SHA256 + SHA1 hash rules. When both hashes are present in the AH event we emit one <Allow> per algorithm (SHA256, SHA1, and their Authenticode variants). App Control evaluates the strongest hash first and ignores any algorithm the running kernel can’t compute, so emitting every variant maximises match rate — exactly what PowerShell New-CIPolicy -Level Hash produces.
• No more empty hash rules. If an event truly has no hash at all (SHA256 / SHA1 / Authenticode all missing), the recommender flags the row for manual review and the exporter writes a clearly-broken placeholder with a <!-- WARNING --> comment instead of an empty Hash="".
• Risk badge now follows the rule type, not just the file location. A SHA256 Hash rule for an unsigned binary in %LOCALAPPDATA% is no longer flagged — Hash pins exact bytes regardless of where the file lives. The RISK badge now only appears for FilePath rules in user-writable folders, FileAttribute / FileName rules for unsigned files in user-writable folders, or anything kernel-mode (.sys).
• Compact, deduplicated supplemental policy export. The supplemental .xml exporter now emits one short section header per rule type (Publisher / FileAttribute / FilePath / Hash) instead of repeating each fragment’s own multi-line comment dozens of times. Files exported with lots of Hash recommendations are dramatically smaller while still being valid input for ConvertFrom-CIPolicy.

🎨 UI polish

• Three slide-in side drawers on the AH page (Advanced & KQL, Policies, Export) driven by toolbar toggle buttons with mutual exclusivity — opening one closes the others.
• Event detail drawer with Prev / Next navigation, resizable thumb (width persists), opens on double-click or Enter.
• Filter bar (search, ActionType, Disposition, Hide Microsoft-signed, Group by Publisher) plus per-row badges (MS / KERNEL / RISK), per-row ✓ checkboxes for selective export, and an Action Plan card.
• BasePolicyID picker — dropdown of known base policies plus a Custom GUID field, so the supplemental policy you export is always parented to the right base.

🛠️ Under the Hood

• New AdvancedHuntingService built on Microsoft.Identity.Client 4.76.0 (interactive auth, FOCI client ID, per-cloud authority + resource URIs, legacy WDATP endpoint fallback).
• New AppControlPolicyComparerService uses Microsoft.Security.CodeIntegrity 3.1.1 to parse .cip / .p7b / .xml policies; sanitises unknown <Option> values so newer Wizard-generated policies load cleanly.
• Bumped application, installer, About screen, and website to 3.1.1.

👤 For Administrators

• MSI: Highwind-3.1.1.msi
• Detection registry key: HKLM\SOFTWARE\Highwind\Version = 3.1.1
• Silent install: msiexec /i Highwind-3.1.1.msi /qn
• Upgrade behavior: The MSI major-upgrade rule automatically uninstalls any 3.0.x / 3.1.0 build when 3.1.1 is installed — no manual cleanup needed.
• New API permission for the Advanced Hunting page: the operator running the app needs Defender for Endpoint AdvancedHunting.Read (delegated). Interactive sign-in walks them through consent on first use; no app registration is required for the default first-party client.
• Preferences file: %LOCALAPPDATA%\Highwind\advanced-hunting-prefs.json stores the chosen cloud, tenant, KQL window, custom policy folder, and the rule-precedence order.
• Scheduled tasks & collector behavior: Unchanged from 3.1.0. Existing Intune / SCCM / GPO deployments and Function App ingestion continue to work without changes.

Download 3.1.1 from GitHub All download options

Previous Releases

Full release notes and downloads for older versions live on the GitHub releases page.

View all releases on GitHub →