You built a weapon to protect people. The people who hired you to protect them confiscated it. That’s not a metaphor — that’s exactly what happened when a team of security researchers built a Rust-based EDR (Endpoint Detection and Response) tool for macOS, and Apple’s notarization system tried to strangle it in the crib.
When the immune system attacks the cure, the disease wins.
Let me back up. If you’re a developer or security practitioner on macOS, you already know the notarization dance. Apple introduced it as a trust mechanism — a way to verify that software hasn’t been tampered with before it runs on your machine. Sounds great, right? A notarized app gets the green light. Users feel safe. Apple keeps its walled garden pristine.
But here’s where it gets ugly. An EDR tool — the kind of software that hunts malware, monitors system calls, and catches threats before they spread — has to operate at the same low level as the malware it’s hunting. It needs to see everything. Touch everything. Sit in the same shadows where attackers hide.
And Apple’s notarization system looks at that behavior and says: “This looks like malware.”
You can’t build a better lock if the locksmith refuses to let you see the door.
The Nemesis Labs team built their EDR in Rust — memory-safe, performant, modern. This wasn’t some weekend hack project. This was serious engineering aimed at giving macOS users a security layer that goes beyond what Apple ships natively. And the platform’s own security apparatus treated it like a threat.
Think about that for a second. The very mechanism designed to protect users is blocking the tools that could protect them better. Apple’s notarization doesn’t just verify code integrity — it makes editorial decisions about what kinds of software are allowed to exist on the platform. And security research software that behaves like malware (because it has to) gets caught in the same net.
This isn’t a bug. It’s a philosophy.
Apple has spent years building the narrative that they are the security layer. Gatekeeper, Notarization, SIP, TCC — each one another brick in the wall. And to be fair, those bricks have value. macOS is safer than it was a decade ago. But the implicit message is: you don’t need third-party security because Apple has you covered.
Except Apple doesn’t always have you covered. No single vendor catches everything. The entire security industry is built on the principle of defense in depth — multiple layers, multiple perspectives, multiple tools watching for different signals. When you flatten that to one vendor’s worldview, you create blind spots. And attackers love blind spots.
A walled garden doesn’t keep the pests out — it just decides which pests are allowed.
The frustration here isn’t just technical. It’s existential. If you’re a security researcher, you’re watching the largest desktop platform in the enterprise slowly close the door on independent security tooling. Not maliciously — that’s what makes it insidious. Apple isn’t banning security tools. They’re just making it structurally impossible to build the ones that actually work, because the ones that actually work look exactly like the things they’re trying to block.
And who loses? You do. The user who assumes their Mac is protected because Apple said so. The enterprise security team that can’t deploy the EDR they need because it won’t pass notarization. The open-source contributor who watches their tool get rejected for doing exactly what it was designed to do.
The Rust EDR from Nemesis Labs isn’t just a story about one tool. It’s a canary in the coal mine. It’s the moment where platform security and third-party security stopped being allies and started being competitors. And when the platform owns the gate, the gatekeeper always wins.
The most dangerous security flaw isn’t in the code — it’s in the assumption that one company can protect you from everything.
So what happens next? Either Apple opens a legitimate path for deep security tooling on macOS — real system extensions that don’t hobble EDR into uselessness — or the independent security ecosystem on Apple platforms withers. Not with a bang, but with a thousand rejected notarization requests.
If you build security tools, this is your fight. If you use a Mac and assume you’re safe, this is your blind spot. And if you’re Apple, well — you might want to decide whether you’re building a platform that’s secure, or a platform that’s just yours.
Because those aren’t the same thing. And the difference is where the threats live.
FAQ
Q: Isn't Apple just protecting users from actual malware?
A: No — Apple is conflating behavior with intent. An EDR tool that monitors system calls looks like malware because it uses the same APIs. The difference is purpose, not technique. Notarization can't tell the difference, and that's the problem.
Q: What does this mean for enterprise Mac deployments?
A: Security teams can't deploy the deep monitoring tools they need because Apple's notarization and system extension framework actively restrict the capabilities that make EDR effective. You're left with Apple's native security — which is good, but not complete.
Q: Is Apple doing this on purpose to kill competition?
A: Probably not deliberately, but the effect is the same. Apple's security philosophy centers on their own tools as the primary layer. Whether it's intentional control or structural oversight, the result is that independent security tooling gets squeezed out. Intent doesn't change the outcome.