Architecture
PatchPilot is a single system an MSP runs itself, built to bridge the gap between vulnerability management and remediation across every customer tenant it manages. It doesn’t replace the Microsoft services a customer already pays for — it orchestrates Defender for Endpoint and Intune, using the GDAP relationship the MSP already holds with that customer, with the correct, already-established permissions rather than a new standing credential of its own.
There’s no agent on a customer’s devices and PatchPilot installs nothing on them. Every finding it shows and every fix it applies goes through Microsoft Defender for Endpoint and Intune, in the customer’s own tenant — using the access an engineer’s own Microsoft account already has there, for as long as a single request takes and no longer. PatchPilot holds no password or standing key for any customer.
This page is a summary aimed at someone deciding whether to adopt PatchPilot or explaining it to a colleague. The in-app Setup > Architecture page (visible once signed in) is the maintained source of truth, with interactive diagrams you can click into for detail — see Navigating PatchPilot: Setup.
How the engineer and PatchPilot reach a tenant
An engineer signs in with their own Microsoft account, bringing whatever GDAP roles that account already holds in each customer tenant. Their browser only ever holds a session cookie — never a Graph token. When PatchPilot needs to do something in a tenant, it asks Microsoft Entra ID for a short-lived token scoped to that one tenant and nothing else.
- Home tenant (the MSP’s own): reached via the On-Behalf-Of flow — PatchPilot exchanges the engineer’s live sign-in, server-side, for a token. This needs someone actually signed in, which is why an overnight schedule keeps the owning engineer’s renewable credential for up to 90 days; if that engineer stops signing in, their schedules stop with a clear message rather than failing silently.
- Customer tenants: reached through the GDAP relationship set up during onboarding. The token PatchPilot receives inherits exactly the roles the signed-in engineer personally holds in that customer — Microsoft doesn’t allow an application to hold GDAP roles of its own, so there is no mode in which PatchPilot acts as itself.
Remediation options, channels, and catalogs
PatchPilot matches every finding against a set of package/script catalogs to work out the actual fix, then dispatches it through one of several Microsoft-owned channels. Which channel runs is picked automatically — Live Response by default — or an engineer can override it from the Run Now dialog.
Four catalogs feed that decision:
- Winget — the default match for an app finding.
- Chocolatey and the Microsoft Store — a small hand-curated fallback for apps winget doesn’t cover.
- Windows Update Catalog — Microsoft’s own live, per-tenant list of quality-update releases.
- Script Catalog — PatchPilot’s library of custom PowerShell for findings that map to none of the above; cataloged, but dispatched manually rather than picked automatically.
Of the remediation channels, three are wired end-to-end today:
| Channel | Latency | Use |
|---|---|---|
| Defender Live Response | Seconds | Ad-hoc script on a single device |
| Win32 app deployment (Intune) | 5–15 min | Packaged Winget upgrade at scale |
| Expedited Quality Update (Intune) | Hours | OS quality patches |
A fourth, Intune’s on-demand proactive remediation, is fully modeled in the data layer (selectable, preflight-checked, present in historical job rows) but not actually dispatched by the worker yet — kept modeled deliberately for a future release rather than removed outright.
How a fix reaches a device
Remediation runs through Defender for Endpoint’s Live Response. The device is already enrolled in Defender and Intune, so there’s no agent for PatchPilot to install — it asks Defender to run a script on the machine and waits for the verdict. The script is published to the customer’s Live Response library once, named by a hash of its own contents, and reused after that. Success is decided from a marker the script prints itself rather than trusting Defender’s reported exit code, since a script can exit zero having done nothing.
Windows Update work (feature updates, quality updates, update rings, driver updates) goes through a separate path, described next.
How Windows updates are identified and delivered
The Windows Updates hub covers four Intune policy types: feature updates and quality updates, which PatchPilot can create and delete, plus update rings and driver updates, which it only reads and displays.
- Quality updates are matched against a real catalog — Microsoft publishes the tenant’s actual list of monthly and out-of-band releases, and PatchPilot either matches a Defender-reported missing KB against it or lets an engineer pick a release directly.
- Feature updates have no such catalog — PatchPilot writes the target Windows version label (e.g. “24H2”) straight into the policy.
Delivery for both is the same shape: create an Intune policy and assign it to a real Entra group. Once assigned, delivery is out of PatchPilot’s hands — the device pulls the policy on its own Windows Update check-in.
Microsoft APIs used
Defender calls go to api.securitycenter.microsoft.com; Intune calls go to
graph.microsoft.com. Every call is made with a delegated token for a
single tenant and recorded in the audit log against the engineer who caused
it.
Network requirements at a glance
Two networks matter, and only one is under the MSP’s control:
- PatchPilot’s own server needs outbound access to the two Microsoft
API hosts above, plus
login.microsoftonline.comfor auth. - Every managed device needs its own outbound access for the Defender sensor and the Intune Management Extension — this is usually the network a remediation job actually stalls or fails on, not PatchPilot’s server. Full current host lists and AV/whitelisting exclusion paths are on the in-app Architecture page’s “Whitelisting requirements” section, since Microsoft revises these lists independently of PatchPilot releases.
See Requirements for licensing and role prerequisites, and Known Issues for what this architecture can’t do yet.