On March 11, a pro-Iranian threat actor called Handala compromised Stryker’s Microsoft Intune environment and remotely wiped over 200,000 devices across 79 countries. Not by exploiting a zero-day. Not by deploying sophisticated malware. By getting access to the tool that Stryker trusted to manage their endpoints — and using it to do exactly what it was designed to do.
CISA published an advisory three days later urging every organization using endpoint management software to harden their configurations. The timing felt personal.
I’ve been a Jamf admin for years. I built Patchable because I was frustrated with how hard it is to keep a Mac fleet patched and compliant without annoying your users or spending half your week on it. But as I was building it, I kept coming back to the same uncomfortable question: what happens if someone gets into Patchable?
Patchable’s privileged helper runs as root on every enrolled device. It can install software, modify system files, and execute scripts. That’s what makes it useful. It’s also what makes it dangerous in the wrong hands.
The Stryker incident is a reminder that endpoint management tools are high-value targets precisely because they’re trusted. They have the keys to everything. An attacker who compromises your patch management tool doesn’t need to find a vulnerability in macOS — they just need to use the tool the way it was designed.
So here’s what we built into Patchable from the start.
Every script is cryptographically signed
Patchable uses Installomator to install and update apps on enrolled Macs. Installomator scripts run as root via the privileged helper. Before any script executes, Patchable verifies a RSA-4096 signature against a public key embedded in the Mac client at build time.
If the signature doesn’t verify — the script doesn’t run. Not a warning. Not a log entry. The script doesn’t run.
The private key lives in exactly one place: the Patchable server’s environment. It’s never in the codebase, never in git history, never on disk. Every script delivered to every enrolled device is signed with that key before it leaves the server. The Mac client rejects everything else.
This means that even if an attacker compromises the Patchable admin portal, they can’t push an arbitrary script to your fleet. They’d need the private signing key too. And that key is not in the portal.
No single login can touch all your devices
The CISA advisory is clear on this: “no single login should ever have the power to cause irreversible damage.”
Patchable enforces multi-admin approval for any bulk action affecting 10 or more devices. Pushing a script, changing a policy deadline, force-updating an app fleet-wide — any action at scale requires a second admin to review and approve before it executes.
This isn’t a feature you configure. It’s on by default.
One person with compromised credentials cannot wipe your fleet. They can request the action. They cannot execute it alone.
The admin portal has the same security controls we tell you to enforce
It would be embarrassing to sell endpoint security software with a poorly secured admin portal. So we didn’t.
Patchable supports passkeys — phishing-resistant authentication that can’t be intercepted the way TOTP codes can. We removed magic links as a primary login mechanism for existing accounts because email-based auth means your email provider’s security becomes your endpoint management tool’s security.
Organizations can restrict admin portal access to specific IP ranges. If your admins only manage the fleet from the office or VPN, lock it to those ranges. An attacker with stolen credentials from outside that range gets a generic 403 — no indication that an allowlist even exists.
Every admin action is logged. Not just stored — monitored. Logins from unrecognized IPs, bulk actions after hours, new admin roles created, MFA disabled — these fire Slack alerts to your admin channel immediately.
Patchable doesn’t trust itself
The Mac client doesn’t trust that it’s talking to a legitimate Patchable server. It pins the TLS certificate. It verifies signatures on every script. It checks that scripts haven’t been modified in transit.
The server doesn’t trust that enrolled devices are who they say they are. Every checkin uses a device-specific API key. Keys can be revoked individually without affecting other devices.
The version checker (vrsn) validates every version it discovers before reporting it. A version string from an LLM-assisted extraction gets a different confidence level than one from the Homebrew Cask API. High-confidence sources like Homebrew and GitHub Releases are preferred. Low-confidence sources require admin review before triggering automated updates.
What we’re still working on
I’m not going to pretend Patchable is done. No software is.
The security hardening sprint we completed this week added multi-admin approvals, IP allowlisting, anomaly detection, and full RBAC enforcement across every API endpoint. Before that sprint, some of those things existed in the UI but weren’t enforced at the API level. That was a gap and we fixed it.
What’s next: the Device Trust feature — using Patchable itself as a verified second factor for IDP authentication, with osquery integration for deep endpoint posture checking. That’s a few months out. When it ships, Patchable will be able to verify FileVault, firewall status, OS version, and CVE exposure before allowing access to corporate resources.
The uncomfortable truth about endpoint management security
Every endpoint management tool has this problem. Jamf, Kandji, Mosyle, Intune — they all run agents with elevated privileges on every managed device. They all have admin portals that can push changes at scale. The attack surface is inherent to what they do.
The difference is whether you’ve thought carefully about what happens when someone gets in — and built accordingly.
The Stryker incident wasn’t a failure of Intune as software. It was a failure of hardening. Default configurations, insufficient MFA, no multi-admin approval for destructive actions. The same failure would be possible in any endpoint management tool deployed with the same lack of care.
Patchable won’t be perfect. But it was designed by someone who has lived with the consequences of poorly secured IT tooling, and who thinks about the attack surface every time a new feature gets added.
If you’re evaluating patch management tools, ask them how scripts are signed. Ask what happens if an admin account is compromised. Ask whether a single login can push changes to your entire fleet. The answers will tell you a lot.
David Minnema is the founder of Machinery Software and a working Jamf admin. Patchable is in early access — join the waitlist if you’d like to try it.