Mac Souverain — Articles (English)

Passwork, « Made in EU » outside, FSB-certified inside

Mac Souverain — Mon, 27 Jul 2026 07:00:00 GMT

Introduction

A software company based in Barcelona. A password manager sold to European public bodies. On the website, until recently, two reassuring lines: “Made in EU 2017” and “no affiliations with any US, Russian, or other non-European entities”.

Small problem. The software is in fact affiliated with Russia. And its source code is certified by the FSB, which had access to it. Barely worth mentioning.

On 17 July 2026, a consortium led by OCCRP and VSquare, with a dozen newsrooms including Le Monde, NU.nl, De Groene Amsterdammer, Investico and De Tijd, published an investigation. The code of this European tool is developed in Russia, in Arkhangelsk, and its updates travel through an entity in the Emirates. The two reassuring lines vanished from the website after the journalists started asking questions.

This piece isn’t only about Passwork. Passwork is just one more example of Brussels’ incompetence. Get this straight, “Made in EU” on a product page carries no legal weight, and protects you from nothing.

Nobody, not Brussels, not a label, checks it for you. So let’s learn to do it ourselves.

The problem: a flag proves nothing

You pick a piece of software to protect your data. You see “European”, you see a head office in the EU, and you decide sovereignty is ticked off. You’ve just confused two things that have nothing to do with each other.

A company’s registration address tells you where its lawyers and its taxes sit. It doesn’t tell you where the code running on your machine comes from. Those are two separate chains: the legal chain, and the software supply chain. The first is easy to display on a website. The second is invisible, and it’s the only one that matters.

Take the case documented by the investigation. Passwork Europe S.L. is indeed registered in Barcelona. But Passwork LLC is registered in Arkhangelsk, Russia, in November 2022. Same logo, a common code base at the origin, and user manuals the investigation calls “virtually indistinguishable aside from the language”. On the two versions released in early April 2026, a researcher notes an install script of around 517 lines that he describes as “basically identical”.

Two products presented as separate. One code base, or nearly.

The point isn’t “a Russian company, that’s bad”. The point is more uncomfortable: nothing on the product page let you know. The “Made in EU” label did exactly the job it exists for, reassuring you, without proving anything.

The mechanism: the three questions the label never asks

A tool’s sovereignty can’t be read off a flag. It’s read off three concrete questions, and not one of them shows up on a sales brochure.

Who ships the binary?

The code you use isn’t the one sitting in a public repository. It’s the one that lands on your machine at the next update. So the real question is: which entity builds and delivers that update?

In the Passwork case, the cofounders Ilya Garakh, who owns the domains, and Andrey Pyankov, a manager, operate through Passwork FZ-LLC, registered in Ras Al Khaimah, in the Emirates, in July 2022. It’s this entity that supplies the updates to the European branch. Passwork describes it as “limited product related knowledge-transfer support” during a transition period meant to end in August 2026.

Translation: the European binary is, at least until that date, fed from outside Europe. A researcher quoted in the investigation sums up the EU/Russia split as “technically shallow”.

Who signs the code, and with which key?

A legitimate update is cryptographically signed. That’s what guarantees the file you install really comes from the vendor and hasn’t been tampered with along the way. Except a signature guarantees origin, not innocence. If the entity holding the signing key is also the one that could slip something into an update, a valid signature protects you from nothing. It just certifies the parcel really came from the sender, whatever the contents.

It’s the update channel, not the storage, that concentrates the risk. A researcher quoted in the investigation describes it as “the most elegant and hardest-to-detect attack vector”. OCCRP itself draws the parallel with SolarWinds, that 2019-2020 attack where a perfectly legitimate monitoring tool served as the vehicle for a massive compromise, through its signed updates.

Let’s stay precise: to date, no backdoor has been found in Passwork, no leak, no compromised client. We’re talking about a vector that exists, not an attack that took place. The channel would allow, structurally, what SolarWinds proved possible. This isn’t an accusation. It’s a geometry.

Which state got to review the source?

Here’s the question nobody thinks to ask, and it may be the heaviest.

Passwork LLC is certified by FSTEC, which VSquare ties to the Russian Ministry of Defense, and by the FSB. These certifications aren’t administrative rubber stamps. The process requires the source code to be submitted to accredited laboratories, tasked with detecting “vulnerabilities or undeclared capabilities”.

In other words: a state organized the review of this software’s source code. Not the European Union. Not an auditor you hired. A service under another jurisdiction, with its own priorities.

When you install a piece of software, you’re not just trusting the vendor. You’re trusting, without knowing it, everyone who had their hands in its code before you.

The regulatory maze that saw nothing coming

At this point you might tell yourself this is exactly what we pay regulators for. Europe churns out digital regulation by the yard, a fresh acronym every quarter, a triumphant press release for every text passed. So this Russian vault dressed up as a European product, sold to its own public bodies, did they see it coming? No. Not one alert, not one line.

Look at the regulatory stack meant to cover this ground. The Cyber Resilience Act imposes “by-design” security on digital products: how they’re built, not by whom or from where. The Cyber Solidarity Act, in force since 4 February 2025, organizes crisis response: a European alert system, a cybersecurity reserve, a post-incident review. Useful the day the house is on fire, silent on who lit the match. And ENISA’s certification schemes, the EUCC for products, the EUCS for cloud, assess assurance levels against technical criteria.

Look through all of that for the box marked “which entity ships the binary” or “which state reviewed the source”. It doesn’t exist. None of these texts certifies a product by its real origin, and none of them bans anything on that basis. A company can display “Made in EU”, have its code reviewed by a foreign intelligence service, and stay perfectly compliant with Brussels. Compliant, stamped, spotless on paper. That’s the level of protection you were sold with billions poured into European cybersecurity and press conferences.

While this vault, whose Russian strain is FSB-certified, thrived on the European public market, where was the same Union pouring its energy? Into trying to force messaging apps to scan your private conversations before encryption, the CSAR (Chat Control 2.0). Translation: Brussels couldn’t spot a tool reviewed by a Russian service and sold to its own public bodies, but it wants to search the messages of hundreds of millions of Europeans. Incompetent on the real threat, zealous about surveilling the innocent.

Read next: Chat Control 2.0, the EU wants to read your messages before you send them and NIS2 forces you to encrypt, CSAR forbids you from really doing it

The conclusion is unpleasant but clear. Software sovereignty isn’t delegated to a regulator. It’s on you. You, the citizen. You, the small business.

What this changes in practice: your verification checklist

Good news, you don’t need to be a cyber-defense analyst. You need a method. Before you hand your passwords, your contracts or your accounts to a piece of software, run it through these six questions. Take the most sensitive example there is, a password vault, the one that holds the keys to everything else.

Who ships the binary? Look for the entity that actually publishes the updates, not the one that cashes your invoice. Company register, legal notices, corporate history. A European address on the homepage and a parent company elsewhere is a signal, not an answer.
Who signs the code, and with which key? A serious vendor publishes its signatures and lets you verify them. Look at who holds the signing key and where. A key controlled by an entity under an opaque jurisdiction cancels the benefit of the signature.
Which state got to review the source? National certifications are public. An FSTEC or FSB certification means the code was reviewed by accredited Russian labs. Conversely, an ANSSI visa (like the one earned by KeePassXC) means a French evaluation. That’s not neutral: ask yourself which state you’re willing to let look under the hood.
Self-hosted or cloud? Software you host yourself takes the vendor out of the storage loop. Your data stays on your infrastructure, under your jurisdiction. It doesn’t solve the update-channel problem, but it shrinks the surface. The vendor’s cloud, on the other hand, stacks both dependencies.
What update history, through which channel? A mature project has a readable changelog, a stable and documented distribution channel. Opaque updates, a channel that keeps changing, an exotic distribution entity: so many red flags. The channel is the real entry point, watch it as such.
Is the code auditable? Open source doesn’t magically make software safe, but it makes lying harder. Public code could have been read by anyone, including people with no interest in reassuring you. Closed code asks you to take the vendor at its word, and you’ve just seen what words on a product page are worth.

None of these six questions needs a budget. They need ten minutes and the will to look behind the flag. Apply them to your current manager tonight. Some will pass the test without breaking a sweat, others far less so.

Read next: Apple, Bitwarden, KeePassXC or 1Password, the honest comparison of password vaults

The limits: what this checklist won’t tell you

We have to be honest on two points, otherwise we slide into trial by insinuation.

First, fairness to the vendor in question. Passwork claims its independence, says the transition with the Russian entity ends in August 2026, and that its clients’ data lives on those clients’ servers. Its CEO, Alexander Muntyan, invokes a “zero-knowledge architecture”, with encryption and decryption on the client side: “we would simply have no data to provide”. This argument deserves to be taken for what it is, a marketing argument, not a technical guarantee. In the self-hosted version, that layer can be disabled, and a server-side layer exists. Above all, zero-knowledge protects the storage, not the update channel, and it’s the channel that worries the researchers.

On the client side, caution too. The investigation establishes that two Irish bodies, the Office of Public Works and the State Laboratory, say they weren’t informed of the product’s origin, the latter now treating the matter as a “potential risk”. Beyond that, on the Russian side Passwork LLC lists clients from the military-industrial complex, including Almaz-Antey, MMZ Avangard, Kometa and Gazprom Neft. Several appear on Western sanctions lists, but under different regimes, EU, United States or export controls depending on the case. No lumping together: neither “all sanctioned by the EU”, nor “all European clients compromised”.

Second, the checklist itself has limits. It doesn’t detect an active compromise, it assesses a structural risk. Software that ticks every box can still be attacked, and software that misses one isn’t necessarily a trap. The checklist doesn’t replace an audit, it stops you from mistaking a sales brochure for proof. That alone is huge.

In short

“Made in EU” is a marketing claim. Not a controlled label, not a legal guarantee, not proof of sovereignty. The Passwork affair shows it without needing a single proven compromise: a piece of software can be registered in Barcelona, coded in Arkhangelsk, updated from the Emirates, and reviewed by a Russian service, all while staying perfectly compliant with the European regulatory stack. That stack, Cyber Resilience Act, Cyber Solidarity Act, ENISA schemes, never asked the right questions. It still doesn’t. Don’t count on it. It didn’t protect you, it reassured you. That’s not the same job.

So ask them yourself. Who ships the binary, who signs the code, which state got to read the source, can you host it yourself, what’s the update channel, is the code auditable. Six questions, ten minutes, applied first to the most sensitive spot there is: the vault where all your passwords live. Sovereignty can’t be read off a flag. It has to be verified. Nobody will do it for you.

Sources

The investigation

OCCRP, European Password Manager Shares Origins and Updates with State-Certified Russian Firm, the primary investigation, 17 July 2026.
VSquare, the same investigation, the consortium’s co-publication.
The Irish Times, How Russian password technology made its way into Irish State agencies, the Irish public bodies among the clients.

The regulatory framework

EUR-Lex, Regulation (EU) 2025/38, Cyber Solidarity Act, the official text, in force since 4 February 2025.
European Commission, EU Cyber Solidarity Act, budget and mechanisms.
EUR-Lex, Digital Europe Programme 2021-2027, the cybersecurity strand.
ANSSI, CSPN-2025/16 certification report (KeePassXC 2.7.9), the ANSSI visa example.

Alerting and total cost, the final tally of your sovereign SIEM

Mac Souverain — Sat, 25 Jul 2026 12:25:13 GMT

Six episodes. A hardened VPS, Wazuh centralising everything, agents across the whole park, CrowdSec at the network, Rspamd at the mail, Santa on the Macs. Your stack is standing, it collects, it detects, it logs.

And it is mute.

A binary blocked on a workstation, a burst of failed logins, an account waking up at 3 in the morning, all of it lands quietly in a dashboard nobody is watching at 3 in the morning. A detection nobody sees go by isn’t a detection, it’s one more log line.

Today, the last episode of the series, we wire up alerting. The brick that turns a SIEM that knows into a SIEM that warns. And then we do what we promised from the very first article, the math. What this stack really costs you, against the bill you’d have been handed in SaaS. The answer is sharper than you think.

Alerting, being warned without being harassed

Wazuh already knows how to send notifications. A dedicated daemon, wazuh-integratord, starts with the manager, reads the alert stream continuously, and pushes every alert above a threshold to the target you’ve pointed it at. The machinery is there. All the work is in the tuning.

First sovereign reflex, look at who receives your alerts. Wazuh ships turnkey native integrations, and that’s exactly the trap, almost all of them are American services, Slack, PagerDuty, VirusTotal. Wiring your sovereign SIEM to Slack means building an entire stack to stay master of your logs, then shipping every one of your security alerts off to an American third party. Dependency sneaking in through the back door.

Two channels stay coherent with what we’ve built. Email, served by the mail server you’ve already been running since the Rspamd episode, which is Wazuh’s historical notification mechanism. And self-hosted chat, a Mattermost or a Matrix sitting on your own infrastructure. Mattermost accepts Slack-format webhooks, so the native slack integration works as-is most of the time, its hook_url pointed at your own server. Retest it on your version, the formats shift from one release to the next.

The configuration lives in ossec.conf, on the manager. Native email is handled directly by the manager, chat channels go through the Integrator via an <integration> block. Email first.

<global>
  <email_notification>yes</email_notification>
  <smtp_server>localhost</smtp_server>
  <email_from>wazuh@your-domain.tld</email_from>
  <email_to>secu@your-domain.tld</email_to>
</global>

<alerts>
  <email_alert_level>7</email_alert_level>
</alerts>

For chat, one <integration> block per channel.

<integration>
  <name>slack</name>
  <hook_url>https://mattermost.your-domain.tld/hooks/xxxxxxxx</hook_url>
  <level>10</level>
  <alert_format>json</alert_format>
</integration>

The field that commands everything is <level>. Wazuh scores each alert on a scale of 0 to 16, and the threshold forwards that value or anything above it. A channel at <level>10</level> will never see a level 6. You can refine with <rule_id> or <group>, but remember one classic trap, when you combine several of these filters, they stack as AND, not OR. The alert has to satisfy every criterion to pass, and plenty of people have wondered why their integration stayed silent for exactly that reason.

That leaves the real question, which level for which channel. Here are the markers I’d suggest, a usage recommendation and not a scale carved in stone by Wazuh, to adjust to your park:

0 to 3, informational noise. You log it, you notify nothing.
4 to 6, low. It lives in the dashboard, not in your pocket.
7 to 9, medium. Grouped email, the team reads it during the day.
10 to 12, high. Failed logins in series, a file integrity breach, a binary blocked by Santa. Real-time chat plus email.
13 to 16, critical. Probable compromise, agent disabled. On-call, you wake someone up.

One <integration> block per channel, each with its threshold. The email digest at 7 for everyone, chat at 10 for the technical team, a custom script to SMS or ntfy at 12 for the manager. The boss doesn’t want to be dragged out of bed for a level 8, and the day you wake him for nothing, he turns the notifications off. That’s how you die.

Because the real risk of alerting isn’t missing one. It’s having too many. A brute-force attack with no deduplication is hundreds of alerts in a few minutes, and a team that learns to ignore them. Deduplication is set upstream, in the frequency and time window of your rules, never at notification time. A SIEM that cries all the time is a SIEM nobody listens to anymore. Alert fatigue is worse than no alerting at all, because it gives you the illusion of being covered.

What the stack actually cost you

The moment of reckoning, cost shown and cost hidden, because selling you “free” would be lying to you.

The visible line is the VPS. Wazuh in single-node mode, manager, indexer and dashboard on one machine, runs comfortably for a 25-to-50-seat SME on 8 vCPU, 16 GB of RAM and 100 GB of disk for three months of retention. At a European host beyond American reach, that rents for between 300 and 1,700 euros a year depending on whether you go for the German budget tier or the high-end French sovereign one. A single line on the invoice, for the whole stack.

The licence line, next. Wazuh, the agents, CrowdSec, Rspamd, Santa, the alerting. Zero. Not a cent, not an enterprise tier, not a per-seat quota. Open source end to end.

And then the line no price sheet shows you, time. Installing the stack, several cumulative days for someone starting out, less for a seasoned sysadmin. Then maintenance, updates, watching the disk, and above all the rule tuning that eats most of the first few weeks. I won’t hand you a figure of hours per month, it would be made up, and none of the ones you’ll read elsewhere rests on anything better than a wet finger in the wind. Count it in person-days, set your rate, do your own sum.

There’s the nuance that holds the whole episode together. Sovereign isn’t free, sovereign shifts the spending from the licence to in-house skill. You no longer pay rent to a vendor, you pay an investment that stays in your own house. The VPS counts in hundreds of euros, time is the dominant line, and the two together stay very far below what the rented equivalent would have cost you.

Episode by episode, the same stack in SaaS

Let’s take the stack brick by brick, and put opposite each one what the market charges for the same function. Assumptions on the table, because without them a figure means nothing, an SME of around forty seats, twenty of them Macs, about five gigabytes of logs a day.

Wazuh replaces a Microsoft Sentinel or a Splunk ES. Count on 7,800 dollars a year for five gigabytes of daily logs on the Sentinel side, from 8,000 to 12,500 dollars on the Splunk side. CrowdSec plays the role of a managed threat intelligence offering, which starts at 1,900 dollars a month at the Platinum tier, close to 23,000 dollars for the year. Rspamd does the work of a Proofpoint or a Mimecast, 1,200 to 8,640 dollars for forty mailboxes. Santa stands in for a Jamf Protect, around 1,440 dollars for twenty Macs. Opposite every line, the same figure, zero in licences.

Add up that right-hand column. Depending on the options kept and without even counting managed EDR or high-end network filtering, the full SaaS equivalent for an SME this size sits between 12,000 and 40,000 dollars a year. Against it, your sovereign stack, between 300 and 1,700 euros in cash, plus your time. Even comparing the worst of the sovereign stack to the best SaaS price, the ratio is on the order of six to thirty times. And the gap isn’t fixed, it widens. The SaaS licence, you pay it again every year for life, at every seat added, at every extra gigabyte ingested. The VPS stays stable, and the install time amortises once and for all.

Two points of honesty. First, the prices I gave you in the first article all hold, Sentinel around 4.30 dollars a gigabyte, CrowdStrike from 60 to 185 dollars a seat, Splunk from 8,000 to 12,500 dollars. Nothing came down. These vendors don’t publish a public rate card anyway, they hide their prices and push you toward volume commitments, which penalises the SME ingesting only a few gigabytes a day. Second, the zero in the sovereign column is a licence zero, not a zero full stop. The cost exists, pooled onto a single VPS line and spread across your time. But the bill on the other side counts by brick, by seat, and by year.

The pitfalls, so you don’t kid yourself

A well-built sovereign stack can age badly. Four points of vigilance, to face head-on.

Retention swells the VPS silently. Three months by default, but the day you want six months or a year of hindsight for an investigation, the disk doubles or triples, and you move up a plan. The sovereign cost isn’t frozen, it grows with your retention and your agent count. Anticipate it at sizing time.
The single node is a single point of failure. The whole stack on one VPS is also one single target. Your encrypted off-site backups, laid down back in the socle episode, aren’t optional. Multi-node exists, but it falls outside an SME’s scope.
Hosts raise prices too. Sovereign doesn’t mean a price locked for life, some raised their rates in 2026. The difference comes down to one word, switching hosts is a VPS migration of a few days. It isn’t a licence contract holding you by the throat.
Tuning is time-consuming at the start. The first weeks buckle under false positives, and that’s where the quality of everything else is decided. Botch this phase, and you fall right back into alert fatigue.

None of these pitfalls is a dealbreaker. They’re parameters you control, precisely because the stack is your own.

Compliance, the brick that makes the deadline tenable

We opened the series on an obligation, GDPR and NIS2 require you to notify fast. Seventy-two hours to characterise a breach on the GDPR side, a triptych of 24 hours, 72 hours and 30 days on the NIS2 side.

Alerting is the brick that makes that deadline tenable. Collecting and detecting is producing the evidence. Alerting is a human seeing it in time to act. Without calibrated notification, the triptych stays a wish, the stack knows something happened and nobody knows in time. With it, the 72-hour clock starts at detection, not on Monday morning when someone reopens the dashboard. That’s the difference between compliance on paper and compliance that holds up in front of the regulator.

In short, you depend on no one

Step back and look at what you’ve built. Seven episodes, one VPS, open-source bricks, and a setup that sees, blocks, filters, controls and, as of today, warns at the right level without harassing you. What large companies pay a fortune for, you built for the price of a VPS and a few weekends.

But the real gain isn’t on the invoice. It comes down to one sentence, you depend on no one. Three independences.

Legal. Your security logs, the most sensitive material in your information system, live on your European VPS, out of reach of the CLOUD Act. In June 2025, before a French Senate committee of inquiry, Anton Carniaux, director of public and legal affairs at Microsoft France, questioned under oath on his ability to guarantee that a French citizen’s data would never be handed to American authorities, answered, “No, I cannot guarantee that.” With a provider subject to American law, that’s the level of guarantee you’re accepting. None.

Economic. No licence rent, no price shock decided without you. Remember VMware’s customers after the Broadcom buyout, perpetual licences scrapped, subscription forced. AT&T went as far as suing Broadcom, alleging a renewal price hike of more than 1,000 percent. Pay or migrate the hard way, with no say in it. Nobody can do that to your stack.

Operational. Nobody cuts off your access, deprecates a feature you rely on, or imposes a migration schedule on you. You own your stack, your logs, your detection.

The price of those three freedoms is a VPS and skill that stays in your own house. Compare it one last time to a SaaS bill that comes back every year without buying you a single one of them.

That’s where the series ends. Not on a product, on a stance. Sovereignty isn’t a slogan, it’s a sum you’ve just done, and it tips one way only.

What’s next, because you asked for it. A reader wrote to us after this series to ask for a real deep dive into Wazuh, further than the all-in-one of episode 2. Message received. An in-depth Wazuh tutorial is coming soon, homegrown rules, decoders, dashboards tuned just right. Got a request, a typo you spotted, a brick you’d like to see taken apart? Write to us.

Series recap

Seven episodes to build your sovereign security plumbing, brick by brick.

Episode 0, the bedrock of the series. Why an SME needs a sovereign SIEM, NIS2, GDPR, and the cost of doing nothing.
Episode 1, the socle. The hardened VPS beyond the CLOUD Act.
Episode 2, Wazuh all-in-one. Manager, indexer and dashboard on a single node.
Episode 3, agents everywhere. Deployment across your servers, Macs and Windows.
Episode 4, the community network defense. Blocking known attackers before they arrive.
Episode 5, the mail filter. Anti-spam and anti-phishing in front of your mail server.
Episode 6, execution control on the Macs. Deciding which applications are allowed to start.
Episode 7, alerting and total cost. Calibrated notifications and the financial bottom line against SaaS. You’ve just read it.

Technical terms? Check the glossary.

MCP servers, the backdoor into your AI

Mac Souverain — Sat, 18 Jul 2026 15:17:13 GMT

The convenience that sets you up

You install Claude Desktop on your Mac. In a few clicks, you wire up a server that reads your files, another that queries your database, a third that runs commands in your terminal. Suddenly your assistant isn’t just chatting anymore, it acts. It opens your documents, rewrites your code, sorts your folders while you sip your coffee.

It’s impressive. It’s also the exact moment you opened a door onto your machine without keeping the key.

These little connectors are called MCP servers. They are the reason your AI went from chatty to useful. They are also the most poorly understood attack surface in the entire 2026 AI ecosystem. And the problem isn’t theoretical: a design flaw in the protocol exposed roughly 200,000 instances to remote code execution, this past April.

Let’s look at what you’re actually plugging into your Mac when you add an MCP. And above all, how to do it without getting burned.

What an MCP actually is

MCP stands for Model Context Protocol. Anthropic published it in late 2024 as an open standard, and everyone adopted it, Claude of course, the Claude Desktop app as well as the Claude Code command-line tool, but also Cursor, Windsurf, and a good chunk of the AI tools you run into.

The idea is simple, almost obvious. A language model, on its own, only knows how to talk. It can’t open a file, read your database, or send an email. MCP is the standard cable that connects your assistant to outside tools. An MCP server on one side exposes a capability, reading files, querying an API, running a command. The assistant on the other side decides when to use it.

Think of a universal socket. Before, each device had its own proprietary plug. MCP is the single socket where you plug in whatever you want: a connector for your files, one for your calendar, one for your Git repo. Your AI reaches into it on demand.

In practice, the flow looks like this. You ask Claude to tidy up your screenshots. The model notices it has a filesystem MCP server available. It calls it, lists your folder, moves the files. You see the result, not the machinery. The server ran a real action on your disk, decided by the model, triggered by your sentence.

That is exactly where convenience tips over into risk.

Why it’s a backdoor

Run the flow again, but watch who decides and who executes.

You write a sentence in plain language. The model, a statistical box nobody controls line by line, decides which tool to call and with what arguments. The MCP server runs whatever it’s asked to, on your machine, with your privileges. Between the three, there’s no bodyguard. Nobody to raise a hand and say “hold on, are you sure you want to delete that?”.

A poorly designed or outright malicious MCP server is a command executor that obeys a middleman you don’t steer. The model can be manipulated by a hidden instruction, a booby-trapped piece of text in a file it reads, a web page you let it open. That’s called prompt injection. The result: your assistant ends up launching an action you never asked for, through a server that has no reason to say no.

And the real trap is in the configuration. An MCP config file isn’t a tidy little list of preferences. It is, in practice, a shell script in disguise. It defines which executables to launch, with which arguments, which environment variables. Loading an MCP config you haven’t read is running a script you haven’t reviewed, and potentially a malicious one. The twist is that this one looks harmless because it’s tucked inside a JSON file.

The word “backdoor” is earned for one precise reason: you see nothing go by. No confirmation window, no visible trace, no alert. The model decides, the server executes, and you watch the result thinking your AI just did you a favour.

The incident that settled the argument

This isn’t a lab hypothesis. It happened, at scale, in April 2026.

On 15 April, the OX Security research team published a report with a not-so-modest title, “The Mother of All AI Supply Chains”. The finding is brutal: the main interface of the official MCP SDKs, the one that makes the tool and the server talk locally, lets a mere configuration trigger the execution of arbitrary system commands. No input validation, no isolation by default.

The numbers are dizzying:

7,000 and more public MCP servers indexed
150 million and more downloads of the affected SDKs and servers
roughly 200,000 instances estimated vulnerable
10 CVEs issued, including CVE-2026-30615 on Windsurf: a prompt injection via malicious HTML leading to local code execution, rated 8.0 out of 10 in severity

On the Mac side, these aren’t abstract names. Cursor, Windsurf and Claude Desktop use these SDKs, and are concretely affected through their MCP integrations. The researchers validated their attacks on six production platforms. It worked for real.

And here’s the best part, or the worst depending which side you’re on. Anthropic’s response, as reported by OX Security and confirmed several times over, comes down to two words: “by design”. The behaviour is deemed normal, provided the user, or the downstream developer, does the securing work themselves. Anthropic declines to change the protocol.

The argument holds up on paper. A protocol isn’t a sandbox, and no standard is obliged to fence off every use. Except that in practice, Anthropic hands the responsibility for locking down to people who never signed up for it: the individual installing Claude Desktop with no notion of security, the small business plugging in a connector found on a public repo. The fixes come from the downstream tools, Cursor, Windsurf and the others, not from the protocol itself.

Translation: the sandbox is your problem. Better to know it going in, not after.

Further reading: Anthropic’s MCP, a design flaw exposes 200,000 instances, our radar on the flaw and the associated CVEs.

Hardening your MCPs without giving up the convenience

Good news: you don’t have to choose between “AI wired to everything” and “AI unplugged and useless”. The dial can be set. Here’s how to put it in the right spot.

Before diving into the settings, know where it all happens. On Claude Desktop, your MCP servers are managed under Settings then Developer, and the “Edit config” button opens the claude_desktop_config.json file.

When you open it, an MCP config looks like this: a few declared servers, each with its command and its access. Nothing more than a script waiting for its moment.

1. Inventory your active MCP servers. On Claude Desktop, go to Settings then Developer, and click “Edit config”: it opens ~/Library/Application Support/Claude/claude_desktop_config.json. On Cursor, go to Settings then MCP. On Windsurf, the list is reachable from the IDE. Disable any server you didn’t deploy yourself or whose code you haven’t read. If you can’t remember why it’s there, it shouldn’t be.

2. Apply least privilege, seriously. A filesystem MCP server should never point at / or at ~. Give it the specific subfolder of the current project, nothing more. Your assistant doesn’t need full access to your disk to tidy three screenshots.

3. Treat any third-party config as hostile by default. A snippet of config grabbed off GitHub, a file shared on Slack, a colleague’s export, a cloned repo: read the configuration in full before enabling it. The executable paths, the commands, the environment variables. Remember it’s a shell script in disguise. Nobody runs an unknown .sh without reading it. An MCP config .json is the same thing.

4. If you’re on Claude Code, lock it down through config, not through instruction. You can write a rule in your CLAUDE.md along the lines of “don’t enable any MCP server without my say-so”. That documents your intent, but don’t rely on it: you just read why a model that gets manipulated doesn’t always obey instructions. The real lock is in your settings.json. Keep a whitelist of authorised MCP tools there and refuse the rest with permissions.deny, and leave the approval prompt active for any server declared in a project .mcp.json, never auto-approve it. The CLAUDE.md reminds the human of the rule, the settings.json imposes it on the machine.

5. Lock down the servers that listen on the network. Some MCPs run as a small local HTTP server. Check it’s bound to 127.0.0.1, never to 0.0.0.0. Otherwise, a malicious web page opened in your browser can, in the worst case, trigger execution on your machine.

~ % lsof -iTCP -sTCP:LISTEN -nP | grep node
node    41827 demo   23u  IPv4 0x9f3a5c  0t0  TCP 127.0.0.1:8787 (LISTEN)
node    41902 demo   25u  IPv4 0x9f3b1d  0t0  TCP *:8788 (LISTEN)

The first line sits nicely on 127.0.0.1. The second listens on *, so on every interface: that’s the one you need to fix.

6. Update the affected tools. Cursor, Windsurf, Claude Desktop and the frameworks involved shipped corrective releases starting in April 2026. Check the release notes that the flaw is explicitly addressed, not just “various security improvements”.

7. Prefer local over remote. An MCP server that runs on your machine and exposes nothing to the network is far easier to reason about than a remote connector hosted by a third party. Every outside service added to the loop is one more company that can read what passes through, or get compromised in your place.

And before installing a new third-party MCP server, ask yourself three questions. Who wrote it and is the code inspectable? What access does it actually need, and does the config ask for more? What happens the day this server gets compromised? If you can’t answer all three, don’t install it.

In short

MCPs are what make your AI assistant genuinely useful. They are also what connects it to your files, your database, your shell, with your privileges and with no witness. The model decides, the server executes, you see nothing go by. That’s the definition of a backdoor, and April 2026 proved it was wide open for roughly 200,000 installs.

Sovereignty, here, isn’t about unplugging your AI. It’s about knowing what’s plugged in, granting only the strict access needed, and never loading a config you haven’t read. A local MCP server, tightly scoped, whose code you’ve read, is a tool. The same server, pulled from an unknown repo with access to your whole disk, is a vulnerability with a friendly interface.

Inventory your MCPs. Cut the ones you don’t recognise. Trim the access of the ones you keep. The rest is just the good habits you already have for the rest of your machine.

Also worth reading: Your AI can be turned off by the US, build your own and Apple Intelligence, what really leaves your Mac.

Rspamd in front of your inbox, phishing stops at the doormat

Mac Souverain — Thu, 16 Jul 2026 14:03:38 GMT

In the previous episode, you put CrowdSec up front. Your firewall now turns malicious IPs away before they touch your services, and every decision goes up into Wazuh. Your SIEM sees, and it bites.

Except the attack that’s going to cost you dearly won’t come in through the SSH port.

It’ll come in through an email. A fake invoice that mimics your usual supplier, a link that looks like your banking portal, an attachment your accountant will open because opening invoice attachments is her job.

That email crosses your firewall without a sound, because it comes in through a door you left open yourself, port 25. CrowdSec won’t block anything, the sender has a clean IP. Wazuh won’t see anything, nobody told it to look that way.

That’s the blind spot in the setup. Three bricks laid, and the number-one intrusion vector for small businesses still walks in unencrypted.

Today, we plug it. We install Rspamd, a filtering engine that slots in front of your mail server, scores every incoming message and decides its fate. Then we wire its logging into Wazuh, so that every verdict, spam blocked, phishing detected, message delivered, shows up in your single dashboard.

Before you begin

Three things to keep in mind before the first command.

What you need. A mail server you administer, Postfix or Exim, on a hardened server like the one from episode 1. The Wazuh manager from episode 2 in place on your VPS, and the Wazuh agent from episode 3 already installed on that mail server, for the integration part at the end of the tutorial. Administrator access, and Redis, which we’ll install alongside the engine.

What changes. By the end, every incoming message is scored before it reaches your employee’s mailbox. The obvious ones are refused at the door, the doubtful ones arrive marked, phishing attempts raise an alert in your SIEM. You move from a blind inbox to an instrumented one.

What doesn’t change. Rspamd filters incoming mail. It’s not an endpoint antivirus, it’s not a replacement for your employees’ common sense, and it doesn’t protect against an account whose password has leaked, the attacker is then inside, not outside. And Rspamd isn’t infallible, it will fool you sometimes. The question isn’t whether it gets it wrong, it’s which side you set the cursor on when it does.

Rspamd doesn’t say yes or no, it scores

The point that changes everything, and that sets Rspamd apart from classic anti-spam filters.

A binary filter looks at a message and rules, spam or not spam. The result is a door, open or shut, and the real world takes quick revenge on that oversimplification. A legitimate invoice with a shortened link and an attachment gets thrown out, a well-written scam gets through.

Rspamd, on the other hand, accumulates. It runs dozens of checks on the same message, each one reporting a small weight, positive or negative. Sender authentication fails, plus two points. The domain is on a reputable blacklist, plus four. The displayed URL doesn’t match the link’s real URL, plus seven. The message looks like a hundred others already flagged as spam, plus five. Conversely, the sender is properly signed and known, minus one.

At the end, it gets a score, and that score triggers an action based on thresholds you set yourself. The recommended configuration is this one.

Score 4, greylist. The sending server is asked to come back later. A real mail server does it, a spam bot rarely does.

Score 6, add header. The message is delivered, but marked. Your mail client can file it under junk.

Score 15, reject. The message is refused at the door, it never comes in.

Three levels of firmness, not a door. It’s the same philosophy as the SIEM in episode 2, we’re not after certainty, we’re after grading our response to an uncertain signal.

On the architecture side, Rspamd runs as several specialized processes. The proxy worker is the one that talks to your mail server, over the milter protocol, on port 11332. The normal worker computes the score. The controller worker serves the web interface and the learning. You’ll only need to know the first one, that’s the one we wire in.

Step 1, install the engine

On the machine that hosts your mail server. The official Rspamd repository, then the package, then Redis, which Rspamd needs for its statistics, its Bayesian filter and its greylisting.

curl -fsSL https://rspamd.com/apt-stable/gpg.key | sudo gpg --dearmor -o /usr/share/keyrings/rspamd.gpg
echo "deb [signed-by=/usr/share/keyrings/rspamd.gpg] https://rspamd.com/apt-stable/ $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/rspamd.list
sudo apt update
sudo apt install rspamd redis-server

The apt-stable repository is the production branch, the one you want on a mail server. Rspamd has been on version 4.x since March 2026.

Tell it where to find Redis, in /etc/rspamd/local.d/redis.conf.

servers = "127.0.0.1:6379";

A survival rule with Rspamd, and it holds for the whole tutorial. You never touch the files in /etc/rspamd/ directly. You write your settings in /etc/rspamd/local.d/, which is layered on top of the default configuration. A package update overwrites the first, never the second.

Then set a password for the web interface.

rspamadm pw

It hands you a hash that you copy into /etc/rspamd/local.d/worker-controller.inc.

password = "$2$your_hash_here";

The interface listens on port 11334, locally only. Leave it that way. The series’ doctrine since episode 1, nothing needless on the open internet, you reach it through your Tailnet or an SSH tunnel.

Step 2, wire it in front of your mail server

Rspamd is running, but no message is being handed to it. Your mail server has to submit every incoming email to it before accepting it.

The mechanism is called milter, for mail filter. Your mail server pauses the message during the SMTP transaction, hands it to Rspamd, waits for the verdict, and acts accordingly. The message is judged before being accepted, that’s the whole difference with a filter that sorts after the fact in the mailbox.

On Postfix, three lines in /etc/postfix/main.cf.

smtpd_milters = inet:localhost:11332
milter_protocol = 6
milter_default_action = accept

The line that deserves your attention is the third. accept means that if Rspamd is down, mail passes without filtering. You favor service continuity. The other value commonly chosen is tempfail, which asks the sender to come back later, your mail is protected even with Rspamd down, but a prolonged outage turns into a mail incident. Choose knowingly. For a small business, accept is the reasonable default, provided you monitor the Rspamd service in your SIEM.

On Exim, the wiring goes through the normal worker over HTTP, not through the milter.

spamd_address = 127.0.0.1 11333 variant=rspamd

Reload your mail server, and send yourself a message from an outside address. Rspamd starts scoring.

Step 3, set the thresholds and arm the anti-phishing

The thresholds first, in /etc/rspamd/local.d/actions.conf.

greylist = 4;
add_header = 6;
reject = 15;

These are the recommended values, and they’re deliberately lenient. A reject at 15 means it takes a massive accumulation of negative signals for a message to be refused. That’s what you want at the start, you tighten later, once you’ve read your own logs.

Sender authentication next. Three modules active by default, SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail) and DMARC (Domain-based Message Authentication, Reporting and Conformance). They check three things, that the sending server is allowed to send for that domain, that the message’s cryptographic signature is valid, and that the domain shown in the “From” field is indeed the one that’s authenticated. An email claiming to come from your bank and failing all three is exposed without needing to read a single line of its content.

By default, Rspamd scores these failures but doesn’t apply the policy published by the sending domain. To make it apply that policy, in /etc/rspamd/local.d/dmarc.conf.

actions {
  quarantine = "add header";
  reject = "reject";
}

You now obey what the real domain owner asked the world to do with messages that impersonate it. It’s free, it’s immediate, and it eliminates a whole family of fake senders.

The phishing module last, the heart of the matter. Its basic check is already active, it compares the URL displayed in the link text to the link’s real destination URL, and raises the PHISHED_URL symbol when the two domains diverge. That’s exactly the mechanism of the fake banking link.

You can back it with two public databases of known phishing URLs, in /etc/rspamd/local.d/phishing.conf.

openphish_enabled = true;
openphish_map = "https://raw.githubusercontent.com/openphish/public_feed/refs/heads/main/feed.txt";
phishtank_enabled = true;

No phishing { } block around it, and it’s the local.d rule from step 1 that applies. Rspamd already includes this file inside the module’s section, you write only the content. Add the block, and you get a section inside a section, silently ignored, no error at startup and no feed activated.

A message containing a URL already flagged elsewhere in the world raises PHISHED_OPENPHISH or PHISHED_PHISHTANK, with a heavy weight. CrowdSec’s community logic, transposed to malicious links.

Three other modules work for you without you configuring them. rbl queries the public blacklists of sending servers. fuzzy_check compares the message’s fingerprint to that of spam already flagged by the Rspamd network, a reworded spam keeps a close fingerprint. bayes learns from your own messages, provided you train it.

autolearn = true;

in /etc/rspamd/local.d/classifier-bayes.conf, and Rspamd learns on its own from the messages it classified with certainty. You can also correct it by hand when it gets it wrong, with rspamc learn_spam on a message that slipped through, or rspamc learn_ham on a legitimate one it wrongly marked.

Step 4, put it to the test

Rather than wait for a real spam, you make one.

There’s a standard string for that, the GTUBE, recognized by every serious anti-spam engine and designed to trigger a certain rejection without being real spam. You write it into a test message, and you submit it to the engine with rspamc, the command-line client.

printf 'Subject: test\n\nXJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X\n' > /tmp/gtube.eml
rspamc symbols /tmp/gtube.eml

You should see the GTUBE symbol and the reject action. The GTUBE short-circuits the score computation and forces the rejection directly, that’s the whole point of the test. If you get it, the engine is running, it scores and it rules. You get something like this.

Results for file: /tmp/gtube.eml (0.014 seconds)
[Metric: default]
Action: reject
Spam: true
Symbol: GTUBE (0.00)
Message-ID: undef

No need for a score that blows past the threshold, the GTUBE symbol triggers a passthrough that forces the reject action whatever the total. That’s the expected behavior, your engine does apply the verdict.

Two check commands for later.

rspamc stat

It gives you the engine’s state, the messages scanned, the breakdown by action, the state of the Bayesian filter.

rspamc symbols /path/to/a/real/message.eml

It replays a real message and shows you the detail of the symbols with their weight. It’s your diagnostic tool when a message got through that shouldn’t have, or the reverse. You don’t guess, you read the tally line.

Step 5, feed Rspamd into Wazuh

Rspamd filters, very good. Your SIEM still doesn’t know it. We wire them together, and the series’ loop closes on mail.

Nothing to enable on the Rspamd side. It already writes, by default, one line per processed message in /var/log/rspamd/rspamd.log. A persistent file, on disk, exactly what Wazuh needs. A line looks like this.

2026-07-14 09:41:07 #3421(rspamd_proxy) <7f2c1a>; task; rspamd_task_write_log: id: <a1b2@evil.example>, qid: <4XjK2r1Yz>, ip: 203.0.113.42, from: <facturation@evil.example>, (default: T (reject): [16.40/15.00] [PHISHED_URL,DMARC_POLICY_REJECT,R_SPF_FAIL,BAYES_SPAM]), len: 4021, time: 128.4ms real, dns req: 22

It’s all there. The sender’s IP, its address, the action taken, the score obtained against the threshold, and the full list of the symbols that brought it down. It’s an investigation report per message.

The wiring happens on two machines, and that’s the point where you trip up if you go too fast. The Wazuh agent, on your mail server, understands nothing of what it reads, it ships the raw lines. It’s the manager, on the VPS from episode 2, that decodes and applies the rules. One machine collects, the other understands.

On the mail server, you tell the agent to read the file. The block goes in its ossec.conf.

<localfile>
  <location>/var/log/rspamd/rspamd.log</location>
  <log_format>syslog</log_format>
</localfile>

You recognize the <localfile> from episode 3, the mechanism by which Wazuh swallows any log source.

On the manager, now, and on it alone. A decoder extracts the useful fields from the line, in /var/ossec/etc/decoders/local_decoder.xml.

<decoder name="rspamd">
  <prematch>rspamd_task_write_log: </prematch>
</decoder>

<decoder name="rspamd-verdict">
  <parent>rspamd</parent>
  <regex type="pcre2">ip: (\S+?), .*?\(default: \S+ \(([\w ]+)\): \[(-?\d+\.\d+)/</regex>
  <order>srcip, rspamd_action, rspamd_score</order>
</decoder>

Then rules that turn those fields into graded alerts, in /var/ossec/etc/rules/local_rules.xml, still on the manager.

<group name="rspamd,">
  <rule id="100400" level="0">
    <decoded_as>rspamd</decoded_as>
    <description>Rspamd, scan verdict.</description>
  </rule>

  <rule id="100401" level="12">
    <if_sid>100400</if_sid>
    <match>PHISHED_</match>
    <description>Rspamd, phishing detected, sender $(srcip).</description>
  </rule>

  <rule id="100402" level="10">
    <if_sid>100400</if_sid>
    <field name="rspamd_action" type="pcre2">^reject$</field>
    <description>Rspamd, message rejected, sender $(srcip).</description>
  </rule>

  <rule id="100403" level="5">
    <if_sid>100400</if_sid>
    <field name="rspamd_action" type="pcre2">^add header$</field>
    <description>Rspamd, message marked as spam and delivered, sender $(srcip).</description>
  </rule>
</group>

The order of declaration isn’t cosmetic, it’s the heart of the tuning. The parent rule is at level 0, it decodes without alerting, otherwise your dashboard drowns under legitimate messages. Phishing goes first, at level 12, because Wazuh fires only one rule per message, the first in the list that matches. A phishing fake invoice is also a rejected message, and if you declare the rejection before it, it comes out at level 10 and the alert you were waiting for never comes. Then the rejection at 10, and the marked-but-delivered spam at 5.

Same logic on the anchoring. ^reject$ and not reject, because Rspamd also has a soft reject action, a mere temporary deferral, which contains the word and would trigger a rejection alert for a message that’s nothing of the sort.

Don’t take this decoder on faith, test it. Wazuh has the right tool, and it lives on the manager, not on the agent.

sudo /var/ossec/bin/wazuh-logtest

You paste a real line from your rspamd.log, and it shows you what it made of it, phase by phase, decoder recognized, fields extracted, rule triggered. If srcip and rspamd_action don’t come out, it’s the extraction pattern that needs adjusting, and you’ll know in thirty seconds instead of waiting in vain for an alert that will never come. Take a rejected-phishing line for your test, it’s the case that stresses the order of your rules. On the example line above, you’re aiming for a result of this shape.

**Phase 1: Completed pre-decoding.
	full event: '2026-07-14 09:41:07 #3421(rspamd_proxy) <7f2c1a>; task; rspamd_task_write_log: id: <a1b2@evil.example>, qid: <4XjK2r1Yz>, ip: 203.0.113.42, from: <facturation@evil.example>, (default: T (reject): [16.40/15.00] [PHISHED_URL,DMARC_POLICY_REJECT,R_SPF_FAIL,BAYES_SPAM]), len: 4021, time: 128.4ms real, dns req: 22'

**Phase 2: Completed decoding.
	name: 'rspamd'
	srcip: '203.0.113.42'
	rspamd_action: 'reject'
	rspamd_score: '16.40'

**Phase 3: Completed filtering (rules).
	id: '100401'
	level: '12'
	description: 'Rspamd, phishing detected, sender 203.0.113.42.'
	groups: '['rspamd']'
	firedtimes: 1
	mail: false
**Alert to be generated.

Phase 2 yields your three fields, phase 3 fires rule 100401 at level 12, that’s the phishing alert you were waiting for. Don’t take this block for a capture ripped from a production machine, it’s the intended result, not a prod reading. The syslog pre-decoding applied to an Rspamd line that doesn’t have the shape of a syslog log, and the decoder’s extraction pattern, can vary depending on your Wazuh version and the exact format of your rspamd.log lines. That’s precisely what wazuh-logtest confirms on your own machine, phase by phase, before you count on the alert.

Once the test is conclusive, restart both services, each on its own machine. The manager, so it loads your decoder and your rules.

sudo systemctl restart wazuh-manager

And the mail server’s agent, so it takes its <localfile> into account.

sudo systemctl restart wazuh-agent

An IP sends a fake invoice, Rspamd scores it, rejects it, writes it to its log, the Wazuh agent reads it and ships it, the manager decodes it and raises a level-12 alert, it shows up in your dashboard next to your CrowdSec blocks and your SSH authentication failures. In Discover, you filter it on the srcip, rspamd_action and rspamd_score fields, exactly like the rest of your events.

The blind spot is plugged.

If it doesn’t work

Problem, Rspamd is running but no message gets scored

Likely cause, the milter isn’t wired in. Rspamd is waiting on its port, your mail server hands it nothing.

Fix, check that the proxy worker is indeed listening on 11332, and that smtpd_milters points to it in your Postfix configuration. Reload the mail server, not just Rspamd.

Problem, legitimate messages are rejected

Likely cause, your rejection threshold is too low, or a sender you know fails its own SPF, which happens more often than people think.

Fix, replay the message with rspamc symbols, read the symbols that pushed it up. If the culprit is a single, legitimate symbol, raise your reject threshold rather than disabling the module.

Problem, the score learns nothing, the Bayesian filter stays mute

Likely cause, Redis is unreachable. Without it, no bayes, no greylisting, no statistics.

Fix, check the Redis service and the contents of /etc/rspamd/local.d/redis.conf. rspamc stat will tell you whether the classifier has data.

Problem, nothing goes up into Wazuh

Likely cause, three suspects, and you have to sort them out before touching anything. Either the file isn’t growing, or the agent isn’t reading it, or the manager doesn’t know how to decode it. The great classic, the decoder and rules edited on the mail server instead of the manager. There, they’re useless.

Fix, is the file growing? If it’s growing, go to the manager, run a line through wazuh-logtest and see at which phase it breaks. Check while you’re at it that local_decoder.xml and local_rules.xml are indeed on that machine, and that you restarted wazuh-manager after writing them. Don’t reinstall Rspamd over an extraction-pattern issue.

What it cost you

The license, nothing. Rspamd is open source, no paid version, no enterprise tier, no message quota.

The machine, little. The engine is written in C and runs on your existing mail server, alongside Redis. At a small business’s volume, you won’t change server size for this. Keep an eye on your RAM anyway after enabling the Bayesian filter and fuzzy_check, they’re the ones that consume.

Your time, a bit. Count a short hour for the installation, the milter and the Wazuh integration.

And the real price, the calibration. It isn’t paid on installation day, it’s paid over the following two weeks, reading your own logs and raising your thresholds when a legitimate message got thrown out. A badly tuned anti-spam doesn’t cost you RAM, it costs you a customer order lost in a silent rejection. That’s the reason this tutorial starts you off lenient, at a rejection threshold of 15, and tightens afterward. The other way around, you learn the value of a false positive the hard way.

It’s the only serious spending line, and no SaaS spares you it. It too will get it wrong, you just won’t see why.

For those in a hurry

What this article does. We install Rspamd on the mail server, wire it in as a milter in front of Postfix, set the scoring thresholds, enable the anti-phishing and the enforcement of DMARC policies, then feed every verdict into Wazuh via a homemade decoder and rules. The mail layer stops being the SIEM’s blind spot.

Concretely, the commands.

Install the stable repository, rspamd and redis-server via apt.
Point to Redis: servers = "127.0.0.1:6379"; in /etc/rspamd/local.d/redis.conf.
Interface password: rspamadm pw, hash in /etc/rspamd/local.d/worker-controller.inc. Interface locally only.
Wire in the Postfix milter: smtpd_milters = inet:localhost:11332, milter_protocol = 6, milter_default_action = accept in main.cf.
Thresholds: greylist = 4; add_header = 6; reject = 15; in /etc/rspamd/local.d/actions.conf.
Enforce DMARC: actions { quarantine = "add header"; reject = "reject"; } block in /etc/rspamd/local.d/dmarc.conf.
Anti-phishing: openphish_enabled and phishtank_enabled in /etc/rspamd/local.d/phishing.conf.
Learning: autolearn = true; in /etc/rspamd/local.d/classifier-bayes.conf.
Test: GTUBE message then rspamc symbols /tmp/gtube.eml, expected action reject.
Integrate into Wazuh, on two machines: <localfile> on /var/log/rspamd/rspamd.log on the agent side, decoder and rules on the manager side (local_decoder.xml and local_rules.xml, phishing rule declared first), validation with /var/ossec/bin/wazuh-logtest on the manager, then a restart of wazuh-manager and wazuh-agent.

In short

You started from a setup that saw your servers and blocked your network, but let the fake invoice walk in through the front door.

You installed Rspamd in front of your mail server, as a milter, so that every message is judged before being accepted. You tuned the scoring rather than a binary verdict, three levels of firmness, greylist, marking, rejection, with thresholds you control.

You armed the anti-phishing, comparison of displayed and real URLs, public databases of malicious links, enforcement of the DMARC policies of impersonated domains. And you wired all of it into Wazuh, decoder and graded rules, so that a phishing attempt raises a level-12 alert in the same dashboard as the rest.

The whole thing stays with you. No message leaves your server to be analyzed elsewhere, no provider reads your mail to tell you whether it’s clean. That’s the difference between a filter you host yourself and a mail gateway in someone else’s cloud, to whom you hand your entire company correspondence so they can protect it.

One entry door remains, and it’s the one that sits in your employees’ hands. The file downloaded without a second thought, the macro that got authorized, the binary that should never have started. In episode 6 we go down onto the Macs, and we fix the problem by deciding which applications are allowed to run.

Series recap

Seven episodes to build your sovereign security plumbing, brick by brick.

Episode 0, the bedrock of the series. Why an SME needs a sovereign SIEM, NIS2, GDPR, and the cost of doing nothing.
Episode 1, the foundation. The hardened VPS beyond the CLOUD Act.
Episode 2, Wazuh all-in-one. Manager, indexer and dashboard on a single node.
Episode 3, agents everywhere. Deployment across your servers, Macs and Windows.
Episode 4, community network defense. Blocking known attackers before they arrive.
Episode 5, the mail filter. Anti-spam and anti-phishing in front of your mail server. You’ve just read it.
Episode 6, execution control on Macs. Deciding which applications are allowed to start.
Episode 7, alerting and total cost. Calibrated notifications and an honest financial reckoning against SaaS.

Technical terms? Check the glossary.

CrowdSec up front, blocking before they hit you

Mac Souverain — Wed, 08 Jul 2026 06:00:00 GMT

Episode 4: The Community Network Defense

In the previous episode, you enrolled Wazuh agents on all your machines. Servers, Linux, Mac, Windows, every machine sends its logs to the manager through the Tailnet. Your SIEM has lifted its nose from its own logs, your entire park is displayed before it. It sees everything, including attacks.

But here’s the catch. An agent Wazuh observes, as we’ve repeated all throughout episode 3. It tells you that a burst of failed connection attempts has just hit your server, it tells you very well, very quickly, very detailed. But it does nothing to stop it. You have eyes, but no hands.

Today, we give you hands. We install CrowdSec, the first active defense line in the series. An engine that reads your logs like Wazuh, but unlike Wazuh, it draws a conclusion and blocks. The IP that’s hammering your SSH, it puts it outside. The attacker already spotted elsewhere on the community network, it blocks it before it even knocks on your door.

A point raised since episode 1 and still holds true. Almost all your services live in Tailnet-only, invisible from the open internet. But some doors must remain open to the world, a mail server receiving on port 25, a public web presence. Those are the doors CrowdSec guards.

This stack, I use daily. The commands that follow are the ones you’ll type yourself, in order, on your hardened VPS then in your Wazuh manager.

Before you begin

Three things to keep in mind before the first command.

What you need. A hardened VPS like the one from episode 1, up-to-date, with at least one service exposed to the open internet to protect. The Wazuh manager from episode 2, operational, for the integration at the end of the tutorial. Administrator access on the machine. And something to read your own logs, /var/log/auth.log and your service logs, since that’s CrowdSec’s raw material.

What changes. At the end, known malicious IPs no longer reach your services, they hit your firewall before. You also benefit from the community list, millions of signals uploaded by other users, so you block attackers you’ve never seen yourself. And your SIEM finally sees this defense layer, every blockage is uploaded to Wazuh.

What doesn’t change. CrowdSec blocks at the network level, by IP address. It’s not an antivirus, not an exhaustive application firewall, not a replacement for your hardening from episode 1. It’s just another layer, the first one the attacker encounters, not the only one. And it blocks the IP, not the human behind it. An IP changes, defense plays on volume and speed, not infallibility.

How CrowdSec sees and blocks

Before installing anything, understand the mechanism. It’s based on three pieces that pass the baton to each other.

The security engine, the local agent. It reads your logs continuously, auth.log, your server web and mail logs. It passes them through scenarios, behavior rules like “six failed SSH attempts in ten seconds from the same IP, that’s brute force”. When a scenario triggers, the engine takes a decision, it writes this IP to a blacklist for a given duration, four hours by default for brute force.

The bouncer, the executor. The engine decides, but it doesn’t touch your firewall itself, that’s a design choice. The bouncer firewall, the one we’re interested in, applies the decision. It puts the faulty IP into your nftables or iptables. Engine and bouncer are separate, you can have several, one for the firewall, one in front of a reverse proxy web, each applies the same decisions at its level.

The community network, the CTI, for Cyber Threat Intelligence. It’s the multiplier. When your engine blocks an IP, it sends the signal to the central API, the address and the scenario. In exchange, you download the community list, the aggregate of signals from all users. Result, an IP that attacked a server in Poland this morning is already blocked on your machine this afternoon, before its first attempt.

Remember the flow, it commands everything else. Log read by the engine, scenario triggered, decision made, bouncer applies it on the firewall, signal shared, community list downloaded in return.

Step 1, install the engine

We start with the brain, on your hardened VPS. Two commands, one to declare the official CrowdSec repository, one to install.

curl -s https://install.crowdsec.net | sudo sh
sudo apt install crowdsec

The first line adds the CrowdSec repository to your sources list. The second installs and starts the engine.

The installation is smart on one point. At the end, CrowdSec scans the services it detects on your machine and installs the corresponding collections automatically. It sees an SSH server, it installs the crowdsecurity/sshd collection. An Nginx, it adds the web scenarios. You don’t have to guess what to watch, it deduces it from what’s running.

Check what’s been set up.

sudo cscli collections list

You should see the list of active collections, with the enabled mention. If a service isn’t covered, install its collection manually, for example sudo cscli collections install crowdsecurity/nginx then restart the service crowdsec. Everything is controlled with cscli, CrowdSec’s command-line tool, the equivalent of your agent_control on Wazuh’s side.

At this stage, the engine reads, analyzes and decides. But it doesn’t block anything yet. It holds a blacklist that nobody applies. It still needs its hands.

Step 2, put the bouncer that really blocks

The hands, that’s the firewall bouncer. It reads the engine’s decisions and translates them into firewall rules that really refuse traffic.

There are two variants depending on your firewall, one for nftables, one for iptables. Most recent distributions run on nftables by default.

sudo apt install crowdsec-firewall-bouncer-nftables

If your machine is on the old iptables, replace the package with crowdsec-firewall-bouncer-iptables. The principle is the same. A detail for consistency with episode 1, if your firewall runs on ufw, know that ufw relies on one of the two backends depending on your version, check which one before choosing the bouncer variant.

The installation makes the connection itself. The package calls cscli bouncers add for itself, registers the bouncer with the engine and gives it an authentication key. No manual key handling.

Check that the engine and its bouncer talk to each other.

sudo cscli bouncers list

You should see your firewall bouncer listed, with a recent last activity date. From now on, the loop is closed. The engine decides, the bouncer applies, the faulty IP falls into a set blocked by your firewall. Your SIEM has hands.

Step 3, check that it bites

Three commands to make sure the machine is running, and one to put it to the test without waiting for a real attack.

First, the big picture.

sudo cscli metrics

It shows you how many log lines the engine has read, by source, and how many times each scenario has been triggered. If the counters are moving, your engine is seeing your logs. If they stay at zero, it’s not reading anything, and that’s a source issue to fix before going any further.

Next, the current decisions. Add the -a flag, otherwise CrowdSec will only show your local decisions and hide the IP addresses pulled from the community network.

sudo cscli decisions list -a

On a machine exposed for a few hours, it shouldn’t be empty. Each line is an IP address, the scenario that triggered it, and the remaining duration.

Look at the Source column. The CAPI lines are the community’s gifts, IP addresses you’ve never seen knocking on your door and are already being refused. The line in bold is yours, a scanner your own server caught in the act and banned all by itself, three hours in the corner. The collective and the local, side by side, in the same blacklist.

Finally, the test. Instead of waiting for an attacker, you create a test decision on a dummy IP address.

sudo cscli decisions add --ip 192.0.2.1 --duration 4h --reason "test block"
sudo cscli decisions list

The IP address 192.0.2.1 belongs to a reserved range for documentation, it won’t block anyone real. You see it appear in the list, the bouncer pushes it into your firewall. Clean up behind you once the test is successful.

sudo cscli decisions delete --ip 192.0.2.1

If adding, displaying, and deleting work properly, your engine-decision-bouncer chain is operational end-to-end.

Step 4, the community signal, what goes out and what stays

This is where CrowdSec scales up, and it’s also the only place where honesty about sovereignty demands a sentence, so let’s put it out there without beating around the bush.

By default, your engine is registered with the central community API. You can check this with:

sudo cscli capi status

This exchange works both ways, and it’s important to know exactly what’s going on. What goes out from your end, when you block an IP address, is a minimal signal: the faulty IP address, the scenario that triggered it, and the timestamp. What never goes out, are your logs, your machine names, your users, the content of anything. CrowdSec shares the conclusion “this IP address is attacking”, not the raw material that led to it. What comes in, is the community list, the anonymized aggregate of these signals across the entire network.

It’s a compromise, and it’s a clear one. You exchange the address of attackers, data that isn’t yours but belongs to your attackers, for collective protection that you couldn’t build alone. The engine remains self-hosted on your end, no third party pilots your blocks, no decision depends on a remote service that could be cut off. You can even opt out of sharing and run purely locally, you keep your defense, you just lose the community list. The balance is in your hands, as always in this series.

If you want a web console to visualize your alerts, CrowdSec offers one, for free, where you enroll your engine with sudo cscli console enroll <your-key>. Optional, and hosted by CrowdSec, so weigh it according to your line. Your real dashboard, anyway, is Wazuh, and that’s the next step.

Step 5, make CrowdSec show up in Wazuh

Your firewall blocks, great. But for now, your SIEM doesn’t know. CrowdSec acts on its own, Wazuh looks elsewhere. We connect them, so that every CrowdSec decision becomes a visible alert in your single dashboard.

The principle is simple and clean. CrowdSec knows how to write its alerts to a file, and Wazuh knows how to read a log file. We make them meet.

On CrowdSec’s side, you enable the file notification plugin. It already exists, you edit /etc/crowdsec/notifications/file.yaml to make it write in JSON format, one alert per line.

type: file
name: file_default
log_level: info
format: |
  {{range. -}}
   { "crowdsec": { "program": "crowdsec", "alert": {{. | toJson }} }}
  {{ end -}}
log_path: "/var/log/crowdsec/crowdsec_alerts.json"
rotate:
  enabled: true
  max_size: 500
  compress: true

Then you declare this channel in /etc/crowdsec/profiles.yaml, so the engine sends its alerts there.

notifications:
    - file_default

A detail that counts. The official CrowdSec tutorial writes this file to /tmp, which is emptied on every machine reboot. We put it in /var/log/crowdsec/ instead, so your alert history survives a reboot. A crowdsec service restart, and the /var/log/crowdsec/crowdsec_alerts.json file fills up with every decision.

On Wazuh’s side, you tell the local agent, the one from episode 3 already installed on this server, to read this file. You add this block to its configuration, ideally via the shared configuration for the group so you only have to write it once.

<localfile>
  <location>/var/log/crowdsec/crowdsec_alerts.json</location>
  <log_format>json</log_format>
  <label>crowdsec</label>
</localfile>

You recognize the <localfile> logic, it’s exactly the mechanism by which Wazuh swallows any log source. The json format tells it to parse each line as a structured object, and your crowdsec.alert.* fields become queryable in the dashboard.

Restart the Wazuh agent, and the series’ loop is closed. An IP address attacks, CrowdSec blocks it, writes the alert, the Wazuh agent reads it, the manager sends it up, it shows up in your dashboard next to everything else. Your SIEM finally sees its own counterattacks.

A version note, because it matters. This integration via the file plugin assumes a recent engine and Wazuh version. Make sure your CrowdSec is at 1.6.3 or above and your Wazuh is at 4.9.0 or above, the versions from which this integration by the file plugin is officially supported. You’re running on Wazuh 4.x, this integration doesn’t depend on the future 5.0, it works on your current stack.

If it doesn’t work

The deployment of CrowdSec is straightforward, and it usually gets stuck at the same points. Here are the real ones, in the order you’ll encounter them.

Problem, cscli metrics shows zero lines read

Probable cause, the engine can’t find your logs, or it doesn’t have the collection for your service. It’s running, but it’s reading nothing.

Solution, make sure the log source exists at the expected path and that the service’s collection is installed with sudo cscli collections list. Install the missing collection, then restart the crowdsec service.

Problem, an IP address is decided but nothing is blocked

Probable cause, the bouncer isn’t there, or it isn’t talking to the engine. The engine decides on its own, nobody applies anything.

Solution, sudo cscli bouncers list should show your firewall bouncer with recent activity. If it’s absent, reinstall the bouncer package. If it’s present but silent, check that the bouncer service is running.

Problem, the wrong firewall backend

Probable cause, you installed the nftables variant of the bouncer on an iptables machine, or vice versa. The bouncer puts its rules in a system that your firewall doesn’t use.

Solution, identify your real backend, then install the corresponding variant of the bouncer, crowdsec-firewall-bouncer-nftables or crowdsec-firewall-bouncer-iptables.

Problem, nothing shows up in Wazuh

Probable cause, note that this is usually not a CrowdSec problem. The /var/log/crowdsec/crowdsec_alerts.json file grows on CrowdSec’s side. If it grows, the diagnosis is on Wazuh’s side, the <localfile> block and the agent version, not on CrowdSec’s side. Don’t reinstall CrowdSec for a Wazuh reading issue.

The community list makes up half the work

A final word, because this is the point we always underestimate at the start. The day you install CrowdSec, you expect it to learn slowly, to need weeks of traffic before it becomes useful. Wrong.

As soon as the first synchronization, you download the community list, and your sudo cscli decisions list -a populates with IP addresses you’ve never seen. Attackers spotted elsewhere, already blocked at your end. You benefit from the work of tens of thousands of other servers before you’ve even had your first attack.

It’s not magic, it’s volume. Every server that sends up a signal strengthens the defense of all the others. It’s exactly the model that the American SaaS sells you expensively and under its jurisdiction, except here it’s open source, self-hosted, and the shared signal is limited to the address of your attackers.

The turning point is passed. Where your SIEM used to just observe, it now blocks.

For the impatient

What this article does. We install CrowdSec on the hardened VPS to block malicious IP addresses known locally and signaled by the community network. The engine reads your logs and decides, the firewall bouncer applies the block on nftables or iptables, and every decision shows up in Wazuh via a file of alerts read by the agent. The defense goes from “seeing” to “barricading the door”.

Concretely, the commands.

Install the engine: curl -s https://install.crowdsec.net | sudo sh then sudo apt install crowdsec.
Check the detected collections: sudo cscli collections list.
Install the firewall bouncer according to your backend: sudo apt install crowdsec-firewall-bouncer-nftables (or -iptables).
Check the connection: sudo cscli bouncers list.
Check the machine: sudo cscli metrics and sudo cscli decisions list -a (the -a for seeing also the community list).
Test the blocking: sudo cscli decisions add --ip 192.0.2.1 --duration 4h --reason "test" then sudo cscli decisions delete --ip 192.0.2.1.
Check the community sharing: sudo cscli capi status.
Integrate with Wazuh: enable the file notification plugin in /etc/crowdsec/notifications/file.yaml (output /var/log/crowdsec/crowdsec_alerts.json), declare it in /etc/crowdsec/profiles.yaml, then add the <localfile> JSON block to the Wazuh agent’s configuration.

In summary

You started with a SIEM that saw attacks but couldn’t stop them, and now you’re ending with a first line that blocks them.

You installed the CrowdSec engine on your hardened VPS, which reads your logs and decides. You put the firewall bouncer, which applies these decisions on your firewall and really blocks. You connected the community list, which protects you from attackers you’ve never seen yourself, by only sharing their addresses. And you made everything show up in Wazuh, so your control room finally sees this defense layer.

It all stays with you. The engine is self-hosted, no decision depends on a third party, and the only signal that goes out is the IP address of your attackers. The protection collective without the dependence, that’s precisely the sovereign third way, opened in the series’ introduction episode.

You now block at the network level. But your most frequent attacks don’t come through the SSH port, they come through your mailbox. In episode 5, we’ll put the anti-spam and anti-phishing filter in front of your mail server, the most exposed door of all.

A final note on the series. Seven episodes to build your sovereign security plumbing, brick by brick.

Episode 0, the bedrock of the series. Why an SME needs a sovereign SIEM, NIS2, GDPR, and the cost of doing nothing.
Episode 1, the foundation. The hardened VPS outside the CLOUD Act.
Episode 2, Wazuh all-in-one. Manager, indexer, and dashboard on a single node.
Episode 3, agents everywhere. Deployment on your servers, Macs, and Windows machines.
Episode 4, the community network defense. Blocking known attackers before they arrive. You just read this.
Episode 5, the mail filter. Anti-spam and anti-phishing in front of your mail server.
Episode 6, Mac execution control. Deciding which applications get to launch.
Episode 7, alerting and honest cost. Calibrated notifications and honest financial breakdown against SaaS.

Technical terms? Check the glossary.

Install your first AI model locally on Mac

Mac Souverain — Mon, 06 Jul 2026 06:14:39 GMT

Previous Article: We set the stage. Your access to a distant AI model can be cut off overnight by an arbitrary decision, and the only thing still running the next morning… is nothing.

We also mapped out what a Mac Apple Silicon runs locally, from the small model that sorts your notes to the large model that writes.

That was the why. Here’s the how.

Good news up front: you need no technical skill, no command line, and no additional hardware. If you’re reading this on a recent Mac, you already have everything. Count twenty minutes, most of it watching a progress bar.

At the end, you have a capable model that responds entirely on your machine. And to prove it, at the very end, we’ll cut the Wi-Fi.

Read: Your AI can be shut down by the US, build your own

What you need

Three things, and you probably already have them.

A Mac Apple Silicon, that is, an M1 to M5 chip. Most Macs sold since late 2020 have one. If you have an Intel Mac, this method doesn’t apply, efficient local inference relies on Apple Silicon’s unified memory.

A reasonably recent version of macOS, Sonoma (14) or later for the tool we’ll use. If you haven’t updated in a while, now’s the time.

RAM, and that’s where the model choice comes in. Quick refresher from the previous article: on a 16GB Mac, once the system is served, you have 8 to 10GB left for AI, enough to run a 7 to 8 billion parameter model.

On a 32GB, you step up a class, up to a 24 billion parameter model. The golden rule, never choose a model that fills the entire budget, or your machine will struggle or crash.

If you want the RAM budget details and the full model map, it’s all in the previous article. Here, we install.

The tool: LM Studio, zero terminal

There are several ways to run a model locally. For a first step, one deserves to be singled out: LM Studio.

It’s a classic desktop app, with windows, buttons, and a search field. You download your models from an integrated library, click, chat. No command line, no config files to edit, no esoteric maneuvers. It’s local AI presented as a normal app, and for getting started, that’s exactly what you want.

LM Studio is free, for personal and professional use. And on Mac Apple Silicon, it comes with the best engine possible, we’ll get back to that in two minutes.

The curious and the hungry have other options, Ollama on the command line, MLX for going metal. We’ll mention them at the end, once you already have a running model. One thing at a time.

Install LM Studio

Nothing more than an ordinary Mac app.

Go to lmstudio.ai and download the Mac version. The site detects your machine and offers the right build, the one for Apple Silicon. You get a .dmg file, the usual Mac installation format.

Open the downloaded .dmg. A window appears with the LM Studio icon and a shortcut to your Applications folder. Drag the icon to the Applications folder, just like any other app. That’s it, nothing to check, nothing to configure.

Launch LM Studio from Launchpad or your Applications folder. On the first launch, macOS might ask you to confirm opening an app downloaded from the internet, confirm. The app opens on a welcome screen that offers to choose a first model. Let’s go.

Choose and download your first model

This is the crucial step, and the one where we’ll be precise, because not all models are equal and the right choice depends on your RAM.

Stick to the sovereign pick from the previous article. On a 16GB Mac, aim for Qwen2.5 7B, a model under Apache 2.0 license, truly free, that runs the essentials of daily life. On a 32GB Mac, aim for Mistral Small, a 24 billion parameter model, European and also under Apache 2.0, tailored for sustained writing and long document analysis.

In LM Studio, open the search tab, the magnifying glass icon in the sidebar, and type the model name. The library is connected to Hugging Face, the big model hub, so you’ll see several variants of the same model. That’s normal, and that’s where you need to know how to read.

Two things to decode on each variant.

The format. You’ll encounter two words, MLX and GGUF. Just remember this: MLX, the calculation framework made by Apple, is the engine optimized for Apple Silicon’s unified memory. On your Mac, an MLX version runs notably faster than the same one in GGUF, quality equal.

LM Studio comes with this MLX engine, might as well use it. Choose the MLX version of the model whenever it’s available. If a model only exists in GGUF, that’s fine, it still works, just a bit slower.

Quantization. You’ll see labels like 4bit, Q4, Q4_K_M, Q8. That’s the model’s compression level. A raw model weighs a fortune in memory, quantization reduces the precision of its weights to make it fit in your RAM, at the cost of a barely noticeable quality loss.

Q4, or 4bit, is the sweet spot for starting, it divides the model’s weight by about four without you noticing much of a difference. Q8 is more faithful but twice as heavy, keep it for later if you have the RAM.

In practical terms, what you’re downloading:

On 16GB, Qwen2.5 7B in MLX 4bit weighs around 4.3GB. It’s well within your RAM.
On 32GB, Mistral Small 24B in MLX 4bit weighs around 13 to 14GB. It’s within your margin without killing your machine.

Choose the right variant, MLX and 4bit, and click download. A progress bar appears, you can follow the download in the downloads tab. Time for a coffee break, the file is several gigabytes.

A word on version numbers. Models evolve, Mistral Small is already at a revision more recent than the one named in the previous article. Don’t sweat the exact number, just pick the latest Mistral Small 24B offered in MLX in LM Studio, that’s the one you want.

Your first prompt, then cut the Wi-Fi

The model is downloaded. Time for the moment of truth.

Open the Chat tab, the speech bubble icon in the sidebar. At the top of the window, a dropdown menu lets you load a model, select the one you just downloaded. LM Studio loads it into memory, a few seconds, and displays a familiar input field, a conversation, like any other assistant.

If LM Studio offers you a choice of engine, make sure it’s set to MLX. It’s usually automatic when you’ve picked an MLX variant, but a quick check doesn’t hurt.

Type your first prompt. Anything, preferably a real task, to feel what it’s like. “Summarize this text in three points”, “write a polite follow-up email”, “explain the difference between two concepts”. The model thinks for a few seconds, then responds, word by word, entirely from your machine.

And now, the demonstration that wraps up the previous article’s loop.

Cut the Wi-Fi. Click on the Wi-Fi icon in your menu bar and turn it off, or go to System Preferences. Your machine is now offline, cut off from the internet, unplugged from the world. Ask the model another question.

It responds.

There you have it. No request went out, not a single byte of your text left your Mac, and yet it works. That’s what a model running on your machine looks like. When they turn off the distant tap one morning, that one keeps running. You can turn the Wi-Fi back on, the demonstration is made.

Three settings that make all the difference

Your model is running. Three buttons deserve a mention, because they make the difference between a smooth machine and a struggling one.

Context length. That’s how much text the model can keep in mind at once, your question plus its response plus everything you’ve fed it. It’s set when you load the model, expressed in tokens, in the config panel. A high value lets you feed it long documents, but it consumes RAM in proportion. If your Mac is struggling, lower it. If you want it to digest a long PDF, raise it, keeping an eye on your RAM.

Quantization. We talked about it when downloading, it’s the quality-versus-weight lever. If your model is cramped in your RAM, more aggressive quantization (Q4 instead of Q8) makes it fit. If you have room to spare and want the best response, lighter quantization improves quality. You adjust by downloading another variant of the model, that’s the only point where you have to go back through the download process.

Unload the model. As long as a model is loaded, it occupies your RAM, even if you’re not using it. When you’re done, unload it, the eject button in the model selector frees up RAM all at once. Useful habit if you’re switching to a heavy task, video editing, coding, virtual machine, and you want your gigabytes back. Closing the window isn’t always enough, unload explicitly.

Going further

You have a running model, you’ve passed your first offline prompt. The rest is bonus, for when the urge to dig deeper strikes.

Ollama, for the curious of the command line. If the command line doesn’t scare you, Ollama runs a model with a single command. You install the app, open the Terminal, type ollama run mistral-small:24b, and it downloads the model then puts you in conversation, directly in the terminal. It’s sparser than LM Studio, but ruthlessly effective, and it opens the door to automation, plugging a local model into your own scripts via a local API. Ollama also takes advantage of Apple Silicon by using MLX.

MLX in action, for the hungry. The engine LM Studio uses under the hood, MLX, is an Apple framework that you can pilot yourself, with its toolbox mlx-lm. It’s the playground for those who want to maximize their unified memory, test custom quantizations, or run barely-out models. Reserved for those who enjoy the fine mechanics, but that’s where you’ll find raw performance on a Mac.

For most everyday uses, you’ll never go beyond LM Studio, and that’s perfectly fine.

Wrap-up

What you’ve just done. You installed a free app, downloaded a model in MLX tailored to your RAM, passed a first prompt, and verified with Wi-Fi off that nothing was leaving your Mac. Twenty minutes, zero command line, zero dependency on a model that a third-party IA can shut down.

This model is yours. No one can cut it off, charge you per request, or decide one morning that your nationality doesn’t suit them. It won’t replace the best distant model for the toughest tasks, we said so, and that’s not the point. Its value is that it’s there, on your machine, all the time, for the bulk of what you do.

The base is set. Next up, using it for real, for all the tasks you can.

Read: Apple Intelligence: what really comes out of your Mac

Sources

The tool

LM Studio, the desktop app to run models locally, free, with MLX engine on Apple Silicon.
LM Studio, system requirements, Apple Silicon M1 to M4 and macOS 14 or later, 16GB RAM recommended.

The models

Qwen2.5 7B Instruct, MLX 4bit, 4.28GB, Apache 2.0 license, the pick for a 16GB Mac.
Mistral Small 24B, MLX 4bit, around 13GB, Apache 2.0 license, the pick for a 32GB Mac.

Going further

Ollama, run a model with a single command, with local API.
Apple MLX, the framework optimized for Apple Silicon’s unified memory.

Technical terms? Check the glossary.

Deploy Wazuh everywhere, your SIEM finally sees your network

Mac Souverain — Wed, 01 Jul 2026 12:50:41 GMT

In the previous episode, you set up a security console that runs Wazuh on your hardened VPS, acting as a manager, indexer, and dashboard on a single node, with the dashboard locked to Tailnet-only. A fine machine, but for now, it only sees itself.

That’s useful, your server monitors itself, validates your hardening, and reports its own CVEs. But a SIEM that only looks at the server it’s running on is like a camera pointed at its own box. Today, we’re turning it towards the rest of the room.

We’re going to deploy Wazuh agents on your fleet. Your Linux servers, Macs, and Windows machines. Each machine gets a sensor that collects its logs, security events, and file integrity, and sends it all back to the manager. Your SIEM goes from nearsighted to panoramic.

One non-negotiable rule, set from episode 1 and commanding this whole chapter. This communication goes through the Tailnet, never through the open internet. The manager only listens on your private mesh. An agent not in your Tailnet talks to nothing.

This stack, I use daily. The commands that follow are the ones you’ll type yourself, in order, on your manager, then on each machine to monitor.

Before you start

Three things to keep in mind before the first command.

What you need. The Wazuh manager from episode 2, operational. Administrator access on each machine to enroll. And most importantly, each machine to monitor must be a member of your Tailnet, just like your manager. You’ll run tailscale up on each endpoint. Without it, nothing comes back.

What changes. At the end, your dashboard won’t list a single agent, but as many as you have machines. Each one reports its logs, audit configuration, vulnerabilities, and file integrity, all in one place, under your single eye.

What doesn’t change. An agent observes, it doesn’t block anything. It tells you when an application starts, when a file changes, when a connection fails. Deciding which applications have the right to launch on your Macs, that comes later, with another tool, in another episode. Here, we’re just looking. We’re not blocking anything yet.

Opening the right doors, and only those

Before touching any endpoints, a gesture on the manager. Until now, your server hasn’t been listening to the outside world on anything, and the dashboard has been folded onto the Tailnet. Remote agents need to reach the manager on two ports.

Port 1515, for enrollment. That’s the initial handshake, encrypted, where a new agent introduces itself and receives its authentication key.
Port 1514, for reporting logs and events, once the agent is enrolled.

And that’s where your sovereignty comes into play. Those two ports, you open only on the Tailscale interface, never globally.

sudo ufw allow in on tailscale0 to any port 1514 proto tcp
sudo ufw allow in on tailscale0 to any port 1515 proto tcp

You recognize the gesture, it’s the same one as SSH in episode 1, the same one as the dashboard in episode 2. You allow on tailscale0, your encrypted mesh, and nowhere else. The trap would be to type sudo ufw allow 1514/tcp all on its own. That command opens your SIEM to the world’s scanners. Ours keeps it invisible.

Check your firewall status.

sudo ufw status

You should see your two new rules, both marked on tailscale0. If there’s a global 1514/tcp hanging around, get rid of it without hesitation, that’s a breach.

Last thing to note, the Tailscale address of your manager, the one every agent will target.

tailscale ip -4

That’s the address you’ll pass to the agents. Not the VPS’s public IP, it doesn’t listen on these ports anyway. In everything that follows, I’ll note it as <IP_TAILSCALE_OF_THE_MANAGER>.

Step 1, enrolling a Linux server

We start with the simplest one, an Ubuntu or Debian server. Three steps, add the Wazuh repository, install the agent and give it the manager’s address, start it up.

First, the official repository.

sudo apt-get install gnupg apt-transport-https
curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | sudo gpg --no-default-keyring --keyring gnupg-ring:/usr/share/keyrings/wazuh.gpg --import && sudo chmod 644 /usr/share/keyrings/wazuh.gpg
echo "deb [signed-by=/usr/share/keyrings/wazuh.gpg] https://packages.wazuh.com/4.x/apt/ stable main" | sudo tee -a /etc/apt/sources.list.d/wazuh.list
sudo apt-get update

Nothing exotic. You import the signature key for the repository, declare the Wazuh repository, refresh the package list. Standard APT routine.

Then, the installation, with the trick that does all the work. Prefixing the installation command with the WAZUH_MANAGER variable tells the package which manager to enroll with during installation.

sudo WAZUH_MANAGER="<IP_TAILSCALE_OF_THE_MANAGER>" WAZUH_AGENT_GROUP="linux" apt-get install wazuh-agent

The WAZUH_AGENT_GROUP="linux" puts this machine in a group named linux. You’ll see what groups are for later, just remember to assign them now.

Finally, start the service and enable it on boot.

sudo systemctl daemon-reload
sudo systemctl enable wazuh-agent
sudo systemctl start wazuh-agent

And there you go, your Linux server is reporting. If you’re running on RHEL, Alma, or Rocky, the principle is the same, just replace the APT repository with the YUM one and apt-get install with dnf install. The WAZUH_MANAGER variable works the same way.

Step 2, enrolling a Mac

Macs get interesting because macOS has its own rules. Let’s start with the deployment, the twist comes right after.

The Mac agent comes as a .pkg package, and there are two versions, one for Apple Silicon and one for old Intel Macs. On a recent fleet, it’s Apple Silicon.

curl -O https://packages.wazuh.com/4.x/macos/wazuh-agent-4.14.5-1.arm64.pkg
echo "WAZUH_MANAGER='<IP_TAILSCALE_OF_THE_MANAGER>' && WAZUH_AGENT_GROUP='macos'" > /tmp/wazuh_envs
sudo installer -pkg wazuh-agent-4.14.5-1.arm64.pkg -target /

The mechanism changes a bit in form but not in substance. On macOS, deployment variables don’t go in front of the command, they’re written to a temporary file, /tmp/wazuh_envs, that the installer reads on the fly. The result is the same, the agent knows its manager and its group. For an Intel Mac, replace arm64 with intel64 in both lines that mention it.

Then, start the agent.

sudo launchctl bootstrap system /Library/LaunchDaemons/com.wazuh.agent.plist

On macOS, the agent lives under /Library/Ossec/, and its control binary is /Library/Ossec/bin/wazuh-control, with the start, stop, and status verbs if you want to pilot it by hand.

The macOS landmine, TCC and full disk access

Now, the truth that most tutorials gloss over. On macOS, your agent will start, enroll, appear active in the dashboard, and yet remain half-blind.

The reason is TCC, for Transparency, Consent and Control, Apple’s permission system by usage. It filters access to sensitive folders, and it doesn’t cut any corners. The agent isn’t an application in Apple’s sense, it’s a package of binaries. Without explicit permission, it’s refused access to the zones TCC protects. Its file integrity monitoring turns on, but it can’t read what it can’t see.

The workaround is to grant the agent full disk access. On a managed fleet, that’s done properly with MDM, a configuration profile pushed by Jamf or equivalent, that declares the permission once and for all on all machines. On a single machine, you do it by hand in the privacy settings. That’s an extra step on top of Linux, and it’s specific to Apple, so keep that in mind before you’re surprised that the Mac reports less than the server.

Step 3, enrolling a Windows machine

Windows, last one in. The agent installs via an MSI package, in silent mode, from a PowerShell console opened as an administrator.

msiexec.exe /i.\wazuh-agent-4.14.5-1.msi /q WAZUH_MANAGER="<IP_TAILSCALE_OF_THE_MANAGER>" WAZUH_AGENT_NAME="accounting-post" WAZUH_AGENT_GROUP="windows"

Same logic as everywhere, the manager, a readable name for the machine, and its group. The WAZUH_AGENT_NAME is handy on Windows, where you’ll soon have ten machines that look the same, so it’s nice to give them names.

Then, start the service.

Start-Service WazuhSvc

In CMD, that’s NET START WazuhSvc, take your pick. The agent installs under C:\Program Files (x86)\ossec-agent.

What Windows brings specifically is reading Windows event logs, the famous Security, System, and Application trio, where failed login attempts, privilege elevations, and account creations land. And the FIM can monitor the registry, malware’s favorite playground for surviving reboots. Your Windows machine is no longer a black box.

Step 4, verifying that everything’s reporting

Three machines enrolled, time to make sure they’re talking to the manager. Back on the Wazuh server, one command.

sudo /var/ossec/bin/agent_control -l

It lists all your agents with their ID, name, and status. Four possible statuses, and you need to know how to read them.

Active, the agent is connected and reporting. That’s what you want to see everywhere.
Pending, it just enrolled and is waiting for its first full handshake. That’s temporary, give it a minute.
Disconnected, it was connected and isn’t anymore. The manager considers an agent lost if it hasn’t given a sign of life in fifteen minutes.
Never connected, it enrolled but never managed to report. That’s the classic symptom of a closed port or a machine outside the Tailnet.

The same table exists on the dashboard, prettier to the eye. The Agents view shows the count of Active, Disconnected, Pending, Never connected, and the details of each machine, its modules, its last activity. That’s your control room, now populated.

And there’s the shift. Each active machine runs, on itself, exactly the modules your server was running on itself in episode 2. The CIS configuration audit. Vulnerability detection on its packages. File integrity monitoring. Log analysis. Except now, it’s not one machine, it’s your fleet, and everything converges on one screen.

Going further, monitoring a specific folder

By default, the agent monitors sensitive system directories. But you’ve got a folder that matters more than the others, your client data, your accounting, a shared drive. You want to know, down to the second, if anyone touches it.

That’s the FIM’s job, File Integrity Monitoring. And instead of editing each machine by hand, you use groups that you assigned during enrollment. A group shares a configuration, pushed automatically by the manager to all its members. You write once, it applies everywhere.

On the manager, edit the shared configuration file for the relevant group, for example /var/ossec/etc/shared/linux/agent.conf, and declare the folder to monitor in the <syscheck> block.

<syscheck>
  <directories check_all="yes" realtime="yes">/srv/client-data</directories>
</syscheck>

Two attributes to understand. check_all="yes" records everything that characterizes a file, its cryptographic hashes, its size, its owner, its permissions, its dates. Any change is spotted. realtime="yes" asks for real-time monitoring, the alert comes at the moment of the change, without waiting for the next scan.

A note of honesty on that real-time. It’s only available on Linux and Windows. On macOS, the FIM falls back on scheduled scans, periodic. A modification between two passes is only seen on the next pass. That’s not a bug, it’s a macOS limitation, but keep that in mind before you count on an instant alert on the Mac side. Another detail that trips people up, the folder must exist before you restart the agent, or it’s ignored.

If it’s not working

Deploying agents is simple when everything goes right, and it always has the same handful of causes when it goes wrong. Here are the real ones, in the order you’ll encounter them.

Problem, the agent stays in ‘Never connected’

Probable cause, in nine cases out of ten in our case, a network path issue. Either the manager’s ports 1514 and 1515 aren’t open on tailscale0, or the machine isn’t in the Tailnet, or you gave the agent the VPS’s public IP instead of its Tailscale address.

Solution, check those three. On the manager, sudo ufw status should show your two new rules both marked on tailscale0. On the endpoint, tailscale status should confirm it’s in the mesh. And re-read the value of WAZUH_MANAGER, it should point to the manager’s Tailscale address, not its public IP.

Problem, the agent goes from ‘Active’ to ‘Disconnected’

Probable cause, it was reporting, it’s not anymore. The manager cuts off after fifteen minutes without news. Often, the agent service has stopped, or the Tailscale link has dropped.

Solution, check that the service is running. sudo systemctl status wazuh-agent on Linux, Start-Service WazuhSvc on Windows, /Library/Ossec/bin/wazuh-control status on macOS. And take a look at the agent’s log, always in the same place depending on the platform, /var/ossec/logs/ossec.log on Linux, /Library/Ossec/logs/ossec.log on Mac, the installation folder on Windows.

Problem, the Mac is ‘Active’ but isn’t reporting much

Probable cause, the infamous TCC. The agent is running, but without full disk access, it’s blind on the zones macOS protects.

Solution, grant the agent full disk access, by MDM on a managed fleet, by hand on a single machine in the privacy settings.

Problem, the agents are ‘Active’ but the dashboard stays empty

Probable cause, that’s not an agent problem. If the machines are reporting but nothing appears in the interface, the culprit is downstream, between the manager and the indexer. Remember episode 2, Filebeat pushes alerts to the indexer.

Solution, diagnose on the server side, not on the agent side. Check that Filebeat is talking to the indexer and that the indexer is digesting. Don’t waste an hour reinstalling agents that are working perfectly.

The first day is noisy, that’s normal

One last word of honesty, because I’d rather you hear it from me before you figure it out on your own. The day you plug in ten machines at once, your dashboard is going to explode.

Each machine arrives with its configuration audit reporting dozens of deviations from the CIS baseline. Each FIM reports legitimate files that change as they’re used. At first, the noise drowns out the signal, and that’s disorienting.

That’s not a bug. That’s the raw state of a SIEM you’ve just turned on in a real fleet. The work that follows, calibrating rules, filtering out false positives, adjusting thresholds so you’re only woken up when it matters, that’s human work, not magic software. We said it from the start of the series, the hard part isn’t the tech, it’s the tuning. That fine-tuning, that calibrated alerting, that’s episode 7’s payoff.

For now, enjoy. Your SIEM isn’t looking at its own belly anymore, it’s seeing your network.

For the impatient

What this article does. You deploy Wazuh agents on your fleet, your Linux servers, Macs, and Windows machines. Each machine reports its logs, configuration audit, vulnerabilities, and file integrity to the manager. Everything goes through the Tailnet, never through the open internet. You verify the enrollment, extend file monitoring via groups, and weather the first day’s noise.

Concretely, the commands.

On the manager, open ports 1514 and 1515 on tailscale0 only: sudo ufw allow in on tailscale0 to any port 1514 proto tcp, then the same for 1515. Never globally.
Prerequisite, every endpoint must be in the Tailnet (tailscale up).
Linux: add the Wazuh repository, then sudo WAZUH_MANAGER="<IP_TAILSCALE_OF_THE_MANAGER>" WAZUH_AGENT_GROUP="linux" apt-get install wazuh-agent, then systemctl enable --now wazuh-agent.
macOS: curl -O the .pkg arm64, write the variables in /tmp/wazuh_envs, sudo installer -pkg... -target /, sudo launchctl bootstrap system /Library/LaunchDaemons/com.wazuh.agent.plist. Then grant the agent full disk access.
Windows: msiexec.exe /i.\wazuh-agent-4.14.5-1.msi /q WAZUH_MANAGER="<IP_TAILSCALE_OF_THE_MANAGER>" WAZUH_AGENT_GROUP="windows", then Start-Service WazuhSvc.
Verify from the manager: sudo /var/ossec/bin/agent_control -l, aim for ‘Active’ everywhere.
Extend FIM via the group, in /var/ossec/etc/shared/<group>/agent.conf, <syscheck> block with check_all="yes" realtime="yes" (real-time Linux and Windows only, not macOS).

In summary

You started with a SIEM that only saw itself, and you end with a SIEM that sees your fleet.

You opened the agent ports on the Tailnet only, 1514 and 1515 on tailscale0, never globally. You enrolled your three families of machines, Linux in three commands, Macs managing TCC, Windows in silent MSI. You verified the reporting with agent_control -l and in the dashboard, and you extended file monitoring on your sensitive folders via groups.

Each machine you plug in is free on the license side, it’s 100% open source, no limit on agents. Where the American SaaS charges by log volume, by the number of machines, the more you see, the more you pay. With you, seeing more costs nothing.

But you’re observing. You see attacks, you’re not blocking anything yet. In episode 4, you add the first active line of defense, CrowdSec, the community network that blocks known attackers before they even knock on your door. Your SIEM starts to bite.

Series recap

Seven episodes to build your sovereign security plumbing, brick by brick.

Episode 0, the bedrock of the series. Why an SME needs a sovereign SIEM, NIS2, GDPR, and the cost of doing nothing.
Episode 1, the foundation. The hardened VPS outside the CLOUD Act.
Episode 2, Wazuh all-in-one. Manager, indexer, and dashboard on a single node.
Episode 3, agents everywhere. Deploying Wazuh on your servers, Macs, and Windows machines. This one.
Episode 4, community network defense. Blocking known attackers before they arrive.
Episode 5, email filter. Anti-spam and anti-phishing in front of your mail server.
Episode 6, Mac launch control. Deciding which applications have the right to launch.
Episode 7, alerting and honest cost. Calibrated notifications and honest financial breakdown against SaaS.

Technical terms? Check the glossary.

Wazuh: Your all-in-one, homegrown Splunk for the price of a VPS

Mac Souverain — Sat, 20 Jun 2026 13:13:52 GMT

In the previous episode, you set up an empty safe: a VPS on a Swiss host, hardened to the bone, SSH via key, firewall closed, administration behind Tailscale, encrypted backups off-site. A nice machine. But for now… it’s not watching anything!

Today, we’re filling it up. We’re installing Wazuh, the brain of the whole stack, on this single node. Manager, indexer, and dashboard, the three central components of a SIEM, on the same machine. It’s the all-in-one mode, and that’s exactly what a small business needs to start with.

The promise of the series is in one sentence, set at the opening. The functional equivalent of a Splunk, for the price of a VPS. By the end of this article, you’ll have a security console running, seeing your own machine already, and it won’t have cost you a single euro in licensing. Whereas the same perimeter with an American vendor would run from a few thousand to tens of thousands of dollars per year, depending on the size of your fleet, with your logs stored in a very unfavorable jurisdiction.

This stack, I use every day. The commands that follow are the ones you’ll type yourself, in order, on the server from episode 1.

Three components, one machine

Before installing, understand what you’re installing. A SIEM Wazuh isn’t a monolithic block, it’s three roles that pass the baton.

The manager is the brain. It receives logs, runs the analysis engine, correlates events, applies rules, and raises alerts. It’s the one that decides that a sudden spike of failed login attempts at 3 AM deserves to wake you up.
The indexer is the memory. It stores and indexes alerts so you can search, filter, and go back in time. It’s a fork of OpenSearch, the open-source search engine, which is itself a fork of Elasticsearch. Remember this detail, it’ll come back to bite us in the best possible way.
The dashboard is the window. The web interface through which you read all this, accessible on port 443. It queries the manager for configuration and the indexer for data.

A fourth player works in the shadows, Filebeat, the pipe that pushes alerts from the manager to the indexer. You won’t touch it, but when something goes wrong, it’s often the first thing you look at.

In an enterprise, these three components live on separate machines to handle the volume and maintain high availability. For a small business with up to a hundred machines being watched, it’s overkill. The all-in-one mode puts all three on the same server, and that’s more than enough to start with. The official documentation even sizes this mode for 1 to 100 agents.

We’ll come back to the moment when all-in-one isn’t enough later on. But for now, one machine, and let’s go.

Installation in one command

Wazuh offers two paths. The first, step-by-step, installs the indexer, then the manager, then the dashboard separately, editing the configuration files by hand. It’s educational, it’s long, and you don’t need it for a single node. The second is the official assistant, which does everything at once.

We’re taking the assistant.

curl -sO https://packages.wazuh.com/4.14/wazuh-install.sh && sudo bash./wazuh-install.sh -a

Let’s break it down. The curl -sO downloads the installation script from the official Wazuh repository, branch 4.14. The sudo bash./wazuh-install.sh -a runs it with admin rights, and the -a flag means all-in-one, all on one machine. This flag tells the assistant to install and configure the three components on this same machine, generate TLS certificates for secure communication between them, and create passwords.

At the end, the assistant displays the admin password in the console. Note it down, it’s your first key to the kingdom. If you missed it while scrolling through the terminal, you can retrieve it properly with:

sudo tar -O -xvf wazuh-install-files.tar wazuh-install-files/wazuh-passwords.txt

This command extracts, without decompressing onto the disk, the file that lists all the passwords generated during installation. We’ll deal with these passwords in a moment, because passwords generated by a script are just a starting point, not a final destination.

At the time of writing, the stable version is 4.14.5, released on April 23, 2026. The installation URL points to 4.14/, so you’re still getting the latest version of that branch. If a 4.15 has been released when you’re reading this, check the current branch on the release notes page before running the command.

The memory trap, where 90% of installs fail

If there’s one thing you should remember from this episode, it’s this. The number one cause of Wazuh installs that struggle, crash, or die after a few days is poorly configured memory on the indexer.

Remember, the indexer is a fork of OpenSearch, which runs on the JVM, the Java virtual machine. And the JVM reserves a fixed zone of memory for itself at startup, called the heap (or the “heap space”). Too small, the indexer suffocates under the data. Too big, it takes up all the RAM and starves the manager, dashboard, and OS running alongside it on the same machine. That’s the whole point of the single-node setup, three big memory hogs sharing one envelope.

The official rule is clear and simple. The heap is half of the machine’s RAM. And both the minimum and maximum boundaries should be the same.

Why the same? Because if you let the JVM resize its heap on the fly, it spends all its time reallocating memory instead of indexing your logs. By fixing the floor and ceiling at the same value, you’re telling it “here’s your sandbox, not a byte more or less, now get to work”.

You set this in a file, /etc/wazuh-indexer/jvm.options.

sudo nano /etc/wazuh-indexer/jvm.options

Find the two lines -Xms (the lower bound) and -Xmx (the upper bound), and set them to half of your RAM. That’s why episode 1 had you aim for 12 GB of RAM, not 8. On a 12 GB machine, the heap takes up 6 GB, leaving 6 GB for everything else, the manager, dashboard, Filebeat, and the system. Plenty of room to breathe.

-Xms6g
-Xmx6g

Then restart the indexer to apply the new value.

sudo systemctl restart wazuh-indexer

If you started with 8 GB to test, your heap value is -Xms4g / -Xmx4g, and you’re living on the edge with 4 GB left for everything else. It’s tight, but it works.

One last detail for the curious. The “half of RAM” rule also has an absolute ceiling, around 32 GB of heap. Don’t worry about this for now, it’s a good general OpenSearch practice, not a Wazuh-specific limit, and at the scale of a small business, you’re nowhere near it. I’m just mentioning it so you’re not surprised if you run into it later while scaling up a bigger infrastructure.

While we’re on the topic of memory, a related rule. The JVM should never swap. If the system starts using the disk as additional memory for the indexer, performance tanks. On a properly sized VPS, with the heap set to half of RAM, you shouldn’t be swapping. But it’s the first thing to check when things start to slow down.

Locking down the house

The installation gives you a functional console. It also gives you passwords generated by a script and a dashboard that, by default, wants to be accessible. Two things to take back under your control before you take your seat.

Change all the default passwords

The passwords generated during installation aren’t bad in and of themselves, but they’re sitting in a file on the server, and you didn’t create them. Good hygiene dictates that you regenerate everything with your own secrets. Wazuh comes with a tool for this, deposited by the assistant in the indexer.

sudo bash /usr/share/wazuh-indexer/plugins/opensearch-security/tools/wazuh-passwords-tool.sh -a -A -au wazuh -ap <CURRENT_PASSWORD>

The -a flag targets all users, -A applies the change, and the -au / -ap pair provides the current admin user and password. In all-in-one mode, the tool automatically propagates the new passwords to the relevant components. You don’t have to recopy them one by one.

Your new passwords should meet a minimum complexity, 8 to 64 characters, with at least one uppercase letter, one lowercase letter, one number, and one symbol from .*+?-. Generate them with your password manager, don’t make them up on the spot.

Certificates, already there

Good news, you don’t have to do anything on the internal encryption front. The -a flag on the assistant generated a little certificate authority and deposited the certificates under /etc/wazuh-indexer/certs/ and so on. The three components are already talking to each other securely. It’s done, it’s clean, don’t touch it.

The only visible effect is that when you first access the dashboard, your browser will show a security warning because the certificate is self-signed and not recognized by a public authority. That’s normal, and for a dashboard that won’t be exposed to the public, it’s perfectly acceptable. Click through the warning, and you’re in.

A quick note to anticipate the temptation. You might want a “real” certificate, via Let’s Encrypt. Don’t do it here. Let’s Encrypt validates your certificate by verifying that your server responds on the internet, which means you have to open a port to the world. That’s the exact opposite of what we’ve been building since episode 1.

If the self-signed certificate really bugs you, Tailscale can emit a proper certificate for your node without any public exposure. But honestly, for a console that only you’ll be consulting, the self-signed certificate is good enough. We’re not going to punch a hole in the wall we just built to make a browser warning go away.

The dashboard, invisible from the internet

This is the most important security gesture of the episode, and it’s the one that separates a sovereign SIEM from one sitting on the curb. By default, nothing guarantees that your dashboard will stay private. The port 443 serving the interface should never be accessible from the internet.

Your security dashboards, they’re maps of your weaknesses, exactly what an attacker dreams of seeing.

The series’ rule, set in episode 1, is inflexible. No public services. The dashboard lives behind Tailscale, accessible only to you, just like SSH did before it.

Two locks, working together. First, we ask the dashboard to only listen on the Tailscale IP of the server, not on all interfaces. That’s set in its configuration file.

sudo nano /etc/wazuh-dashboard/opensearch_dashboards.yml

Find the server.host line. If it’s set to 0.0.0.0, the dashboard is listening on all interfaces, including the public IP. That’s a no-no. Set it to the Tailscale IP of your server, the one you get with tailscale ip -4, from episode 1.

server.host: "<YOUR_TAILSCALE_IP>"

Then restart the dashboard.

sudo systemctl restart wazuh-dashboard

Next, the firewall, as a belt and braces. We’re following exactly the pattern from episode 1 for SSH, allowing port 443 only on the private network interface, never globally.

sudo ufw allow in on tailscale0 to any port 443 proto tcp

The pitfall to avoid is typing sudo ufw allow 443/tcp on its own. That command opens the dashboard to the whole world. Ours only opens it on tailscale0, your encrypted mesh. The difference is not cosmetic, one exposes your security console to internet scanners, the other makes it invisible.

The result is a dashboard accessible only by a member of your private network. A scan of your public IP reveals nothing. In line with the sovereign promise, and in line with common sense.

The grand tour

Log in. From a machine on your Tailnet, open https://<YOUR_TAILSCALE_IP> in your browser. Certificate warning, click through. Login admin, your new password. You’re in the console.

This screenshot is from a production Wazuh instance already populated with several agents. On your fresh install, you’ll only see agent 000, the server watching itself.

And there’s a pleasant surprise, it’s not empty. You were expecting maybe an inert screen while you deploy agents. Not at all. In all-in-one mode, the server comes with a local agent, with the ID 000, watching itself. Your machine is already under the eye of your own SIEM, before you’ve even touched the rest of your network.

In practical terms, you’ve already got data and several modules running on this node.

SCA, for Security Configuration Assessment, is active by default, without any tuning, and it scans your machine against baseline security type CIS benchmarks. It tells you where your config deviates from best practices, a service too many, a permission too broad, a loose SSH setting. You’ll probably find, validated in black and white, the hardening decisions from episode 1.
Vulnerability detection is on by default, but not active. Wazuh inventories the packages installed on the machine and crosses them with known CVE databases. If one of your packages has a published vulnerability, it flags it, with the reference and severity. A note of honesty, unlike SCA and FIM, which run on their own, the local node scan doesn’t trigger on startup. You have to enable it in the /var/ossec/etc/internal_options.conf file, set vulnerability-detection.disable_scan_manager to 0, then restart the manager. Two minutes later, your own machine is scanned too.
File Integrity Monitoring, or FIM, is watching your sensitive files and alerting you if any of them change. A sudden change in a system file is often the first sign that you’ve got an unwanted guest.
Local log analysis, digesting the machine’s logs and turning them into readable alerts.

And there are the compliance dashboards, ready to go. Wazuh ships with views tagged PCI DSS, HIPAA, GDPR, NIST 800-53, TSC, with report generation. Each alert carries the compliance ID it touches, for example a gdpr_IV_32 tag that points to article 32 of the GDPR on security of processing.

A necessary honesty note on NIS2. Wazuh provides all the functional bricks that NIS2 demands, continuous monitoring, file integrity, vulnerability analysis, configuration control, reporting. But it doesn’t have a NIS2 compliance dashboard ready to click like it does for GDPR.

To follow NIS2 finely, you’ll build your own views, leaning on the GDPR and NIST tags already present. Wazuh gives you the compliance toolkit, it doesn’t make you compliant all by itself. The calibration of rules, retention policy, incident response, that’s all human work. We called it out right from the opening, the hard part isn’t the tech, it’s the adjustment.

For now, your SIEM is seeing itself. It’s watching its own machine, and that’s already precious for validating your hardening. The real jump is when it starts seeing the rest of your network. That’s episode 3, deploying agents, the moment when your SIEM starts really seeing your network.

When all-in-one isn’t enough anymore

The single-node setup isn’t magic, and I’m not going to sell you the opposite. It has a ceiling, and it’s important to know where it is before you hit it.

The metric that matters is EPS, events per second that your machine can handle. A well-dimensioned node, around 16 GB of RAM and 8 vCPUs, can handle around 5,000 events per second. For a small business with up to 50 or 100 machines being watched, with normal log activity, you’re well below saturation. The all-in-one mode holds up just fine.

The day you approach saturation, the symptom is unpleasant. When the ingestion queue saturates, Wazuh doesn’t slow down politely, it drops events it can’t process fast enough. And an event dropped is an alert you’ll never see. A camera that stops recording during rush hour.

When that happens, you switch to multi-node, manager on one side, indexer on the other, or even several of each. Detail against intuition but important, Wazuh scales better horizontally than vertically. Two nodes with medium resources are better than one big node. That’s another project, outside this series, but you know now that the door exists.

For a small business just starting out, remember this, all-in-one is perfect for starting, not designed for infinity. And there’s plenty of room between the two.

What it would have cost you elsewhere

We’ve been teasing this figure since the series opened. Time to put it down, for this specific component.

Wazuh’s licensing cost is zero. It’s 100% open source, under GPLv2 license, and there’s no paid tier. No agent limit, no user limit, no log ingestion limit. Your only expense is the VPS you set up in episode 1, between 15 and 30 euros per month depending on the size, plus your installation and calibration time. And that’s it.

Splunk’s bill has a different face. A warning first, Splunk doesn’t publish its prices officially, so everything that follows is an order of magnitude estimate based on secondary serious sources, not the official quote. With that reservation, the principle is simple, you pay by the gigabytes of logs ingested per day, counted in gigabytes per day.

The challenge is to translate that into a real-world park size, because a price per gigabyte doesn’t mean anything until you know how many gigabytes a small business produces. Useful benchmark, with reasonable security logging, count around fifty megabytes of logs per workstation per day, so around one gigabyte per day for fifteen to twenty workstations. From there, we can put some numbers on it, licensing only, keeping Wazuh in the mirror.

15 workstations, around 1 GB of logs per day. Splunk, around 2,000 to 5,000 dollars per year. Wazuh, the VPS, 180 to 360 euros per year. That’s the point.
50 workstations, around 4 to 5 GB per day. Splunk, around 8,000 to 12,500 dollars per year. Wazuh, the same VPS, to the euro.
100 workstations, around 8 to 10 GB per day. Splunk, around 15,000 to 25,000 dollars per year. Wazuh, still the same VPS.

Beyond a hundred workstations surveilled, we’re in another world on both sides, multi-node clusters on Wazuh, paliers in the tens or hundreds of thousands of dollars per year on Splunk. That’s another scale, outside the perimeter of this series thought for the small business.

The difference isn’t just about money. It’s about trajectory. With Wazuh, your infrastructure cost is flat, you ingest more logs, your VPS handles it, your bill doesn’t change. With Splunk, the meter spins with every additional gigabyte. The more your SIEM sees wide and deep, the more it costs you dear, whereas seeing wide and deep is literally its job.

And there’s the question that started this series, who controls the data. Your logs, they’re the complete fingerprints of your network. With Wazuh, they’re on your machine, in Switzerland, under your control.

With the SaaS American vendor, they’re subject to the CLOUD Act. The price, that’s one thing. Who holds the data, that’s the thing that matters the most.

In summary

You started with an empty safe, and you’re leaving with a security console running.

You installed Wazuh’s three components in one command, manager, indexer, and dashboard on your single node. You set the memory trap that breaks most installs, the indexer’s heap to half of RAM, with identical lower and upper bounds, which justifies the 12 GB recommended in episode 1.

You took back control of security, regenerated passwords, certificates already in place, and especially the dashboard locked down to the Tailnet, invisible from the internet. And you took your first tour of the owner’s deck, SCA, vulnerabilities, file integrity monitoring, local log analysis, compliance dashboards ready to go, all on your own machine, without deploying any remote agents yet.

All for zero euros in licensing, where the same perimeter with an American vendor would run from a few thousand to tens of thousands of dollars per year, depending on the size of your fleet, with your logs stored in a very unfavorable jurisdiction.

But your SIEM only sees itself so far. It’s watching its own machine, and that’s already precious for validating your hardening. The real jump is when it starts seeing the rest of your network. That’s episode 3, deploying agents, the moment when your SIEM starts really seeing your network.

Series reminder

Seven episodes to build your sovereign security plumbing, brick by brick.

Episode 0, the bedrock of the series. Why an SME needs a sovereign SIEM, NIS2, GDPR, and the cost of doing nothing.
Episode 1, the foundation. The VPS hardened outside the CLOUD Act.
Episode 2, Wazuh all-in-one. Manager, indexer, and dashboard on a single node. You’ve just read it.
Episode 3, agents everywhere. Deploying on your servers, Macs, and Windows.
Episode 4, community network defense. Blocking known attackers before they arrive.
Episode 5, mail filter. Anti-spam and anti-phishing in front of your mail server.
Episode 6, Mac execution control. Deciding which apps have the right to launch.
Episode 7, alerting and total cost. Calibrated notifications and honest financial breakdown against SaaS.

Unknown technical terms? Check the glossary.

Your AI can be turned off by the US, build your own

Mac Souverain — Wed, 17 Jun 2026 13:40:54 GMT

Update, July 2026. Fable 5 is accessible again, the directive has been lifted. That doesn’t change the thesis, quite the opposite. Cut off yesterday, restored today, by a decision you don’t control: that’s exactly what depending on a foreign dictate looks like. Your local model, on the other hand, doesn’t need anyone’s permission.

You open your Mac one morning. Your usual AI tool refuses to respond. Not a bug, not a server crash. A polite message explains that access is no longer available in your region. You haven’t done anything wrong. You’re paying your subscription. You’re perfectly in order. But you’re on the wrong side of a border, and someone in Washington has decided that’s enough.

This isn’t science fiction anymore. In June 2026, the US government ordered Anthropic, through an export control directive, to suspend access to its two most advanced models, Mythos 5 and Fable 5, for all foreign nationals, worldwide, including its own employees.

Anthropic had to shut them down for all its clients and is contesting the decision. Access to AI intelligence is becoming what oil, chips, and the dollar already are, a lever of power in the hands of a state.

And you’re at the end of the pipe that just got turned off.

The directive as a revealer

The first reaction, when you read this, is to think geopolitics. Big maneuvers, blocs that clash, topics for editorialists. Except the cut-off doesn’t happen to a bloc. It happens to you, on your machine, on a Tuesday morning.

The asymmetry is total. On one side, a supplier under US jurisdiction, subject to its administration’s directives, free to change its access terms overnight. On the other side, you, who’ve built part of your workflow around this tool. You have no say in the decision. You’re not even the target. You’re a collateral damage of a policy that only concerns you by your nationality or geolocation.

That’s what the directive finally makes visible: access to a remote model has never been a technical given, it’s a political authorization. As long as nothing changes, the authorization is tacit, invisible, comfortable. You end up confusing it with a right. The day it’s withdrawn, you discover you didn’t own anything. You were renting.

Ask yourself one question. If access is cut off tomorrow, what keeps running? If the answer is “nothing,” you don’t have a work tool. You have a dependency.

What depending on a remote model really costs

The remote model is great. That’s true, and acknowledging it doesn’t take away from the rest. It’s more powerful than anything you’ll run locally anytime soon. It updates without you lifting a finger. It doesn’t ask for RAM, installation, or maintenance. For many uses, it’s the most effective tool on the market.

But comfort has a price, and that price doesn’t show up on the bill.

Every request you send to a remote model, it’s your text leaving your machine. Your drafts, notes, documents, ongoing thoughts. They pass through infrastructure you don’t control, in a jurisdiction that isn’t yours, subject to rules you don’t vote for. End-to-end encryption protects the pipe, not the destination. At arrival, your text is read in plain sight by the machine that responds.

Then there’s the continuity dependency, the one no one talks about until it bites. Your access depends on a subscription, a pricing policy, a business decision, and now a state directive. Four levers you don’t control, plus a fourth that a foreign government controls, and that’s the most dangerous one. The day one of them flips, your workflow stops. Not gradually. All at once.

That’s exactly the trap we warned about for cloud storage. Your files on someone else’s server are convenient until the account is suspended. Remote AI is the same deal, applied to how you think and produce.

Read: The cloud, it’s someone else’s computer

The sovereignty reflex, the map of local models

Here’s the good news, and it’s more solid than you think. Running an AI model capable of directly on your Mac is no longer a tinkerer’s fantasy. Apple Silicon’s unified memory, the very thing Apple sells for app fluidity, is precisely what makes local inference possible on a consumer machine.

Before the map, a budget rule, because everything starts there.

First, total RAM isn’t available RAM. macOS and your applications consume some of it permanently. And behind the “Mac” label, there are two very different machines.

The entry-level Mac mini comes with 16 GB of unified RAM. Subtract 6 to 8 GB for the system and your apps, and you’re left with 8 to 10 GB actually usable for AI, and that’s with closing what’s running.

A 32 GB machine follows the same principle, but leaves you around 20 GB of headroom. In this usable budget, two things need to fit at the same time: the weight of the model (the model itself) and the context (what you feed it and what it generates).

The practical rule: never aim for a model that fills up the usable budget. On 16 GB, that means a 4 to 8 GB model once quantized. On 32 GB, you can go up to 14, or even 20 GB. If you overflow, the machine falls back on the disk as memory, and then it lags, or it crashes completely.

So here’s the map of what runs, from most accessible to most demanding.

What a 16 GB Mac already runs. That’s the accessible baseline, and it covers most of your daily volume.

For light work, sorting emails, classifying notes, extracting or anonymizing text, tiny 2 to 3 GB models like Llama 3.2 3B, Gemma 3 4B, and Phi-4-mini are more than enough.

For general work, summarizing a document, drafting a memo, managing your correspondence, querying your own note base, a 7 to 8 billion parameter model around 5 GB does the job: Qwen2.5 7B, under Apache 2.0 license, or Llama 3.1 8B. That’s the workhorse of a 16 GB machine.

To read a scanned PDF or an invoice without sending it elsewhere, Qwen2.5-VL 7B (around 5 GB) or Llama 3.2 Vision 11B also work. The ceiling is a 12 to 14 billion parameter model in tight quantization, around 8 to 9 GB, like Qwen2.5 14B: it fits, but with everything else closed and a short context.

On these repetitive and well-defined tasks, local doesn’t just do the job, it does it better: zero network latency, zero requests billed, and your data doesn’t leave your machine.

What 32 GB unlocks. The jump to 32 GB isn’t a luxury, it’s what opens the next category.

For sustained writing and long document analysis, Mistral Small 3, a 24 billion parameter model under Apache 2.0 license, fits around 14 GB in its quantized version. Gemma 3 27B runs around 16 GB.

For multi-step reasoning, 32 billion parameter models fit with some squeezing: QwQ 32B, DeepSeek-R1-distill 32B, or Qwen2.5 32B occupy 19 to 20 GB in Q4 quantization. Context becomes tight, and on the most demanding reasoning tasks, the gap with a remote model remains real. Local does a lot. It doesn’t do everything yet.

On the coding side, Qwen2.5-Coder 32B nearly matches remote models for everyday programming: completing, explaining, debugging, refactoring.

And what doesn’t fit on 16 or 32 GB. Very large models like Llama 3.3 70B, or 405 billion parameter models like DeepSeek-R1 in its full version, require 64 GB of RAM or more. Don’t kid yourself otherwise.

Now, sovereignty isn’t just about raw power. Two other axes matter.

The first is provenance. Mistral is French and European, making it the natural sovereign choice for an European reader. Llama, Gemma, and Phi are American. Qwen and DeepSeek are Chinese.

A caveat here: since the models run locally, no data leaves your machine, regardless of the model’s origin. Provenance doesn’t matter for data exfiltration, it matters for trust, audibility, and not putting all your eggs in one geopolitical basket.

Running a Chinese model locally doesn’t send anything to Beijing. Choosing an European model is about arbitrating the ecosystem you support and what you can inspect, not about a risk of leakage.

The second axis is licensing. Not all “open” models are equal legally. Mistral Small 3 and several Qwen models are under Apache 2.0, a permissive license that lets you do anything, including professional use.

The community license for Llama is usable, but comes with restrictions. For a sovereign baseline, the free license isn’t a legal detail, it’s the guarantee that no one can change the rules under your feet.

My pick for sovereignty by default, in line with all this. On a 16 GB machine, a 7-8B model covers most of your daily volume: Qwen2.5 7B (Apache 2.0) as first choice, or Llama 3.1 8B. On a 32 GB machine, you upgrade to Mistral Small 3 as your daily workhorse (European, Apache 2.0), backed up by a 32B reasoning model like QwQ or DeepSeek-R1-distill, which you bring out for tougher tasks. To run them, three tools are enough: Ollama and LM Studio for simplicity, MLX for those who want to maximize Apple Silicon.

Read: Apple Intelligence, what really leaves your Mac

The realistic threshold, what local does well

It’s not about slamming the door on the cloud for fun. It’s about knowing what should live on your machine, and what can, eventually, leave.

Local does very well with everything that’s repetitive, sensitive, or simply daily. Sorting, summarizing, writing, correcting, classifying, anonymizing, reading your own documents. For this part of your work, which is most of the volume, you don’t need anyone. It runs without a connection, without a fee per request, without a line of your text leaving your machine.

The cloud remains the winner for the top of the pyramid, the most complex reasoning where every point of performance counts. But a supplement is still a supplement. You don’t lean your daily work on a tap someone else can turn off.

The right stance isn’t “all local” or “all cloud”. It’s partitioning. Local becomes your base, what runs by default, what your daily work and anything touching sensitive data relies on.

The cloud becomes a conscious supplement, something you use for a specific purpose, knowing what you’re sending and never sending what shouldn’t leave. The day they cut off your cloud access, you lose a supplement. You don’t lose your base.

That’s where the argument loops back. If you’re reading this on a recent Mac, you’re already on Apple Silicon. The unified memory that runs these models, you’ve already paid for it. This shift to local doesn’t wait for an investment, or a new machine, or an engineer’s skill. It waits for a decision.

Sovereignty in AI isn’t measured by the power of the model you rent. It’s measured by what keeps running the morning they cut off your access. The remote model is comfort, and power when a task demands it.

Your AI base is what lives on your machine. Install one. Run it once, on a real task, to see. You’ll know, concretely, what you have left when they turn off the tap.

The most down-to-earth question left: how do you install all this, concretely? That’s the subject of the next article, step by step, from download to first prompt, without indigestible command lines.

Read soon: Installing and running your first local model on Mac, the step-by-step guide

Sources

The trigger, US directive and Anthropic

Anthropic, Statement on the US government directive to suspend access to Fable 5 and Mythos 5, Anthropic’s official statement, applying the export order while contesting it (12 June 2026).
TechCrunch, Anthropic’s safety warnings may have just backfired, the global shutdown of Fable 5 and Mythos 5 (12 June 2026).
The Register, US clampdown on Anthropic models sends EU sovereignty surge into overdrive, how the cut-off accelerates Europe’s sovereignty shift, the very angle of this article (15 June 2026).

Open-weight models cited

Mistral AI, Mistral Small 3, the 24B Apache 2.0 European pick (30 January 2025).
Qwen, Qwen2.5, the Qwen2.5 family, 7B variants under Apache 2.0.
Meta, Llama 3.1 Community License, permissive license with restrictions.

Local execution on Apple Silicon

Ollama, running models locally, data that doesn’t leave your machine.
LM Studio, desktop app for running LLM privately, supports MLX on Mac.
Apple, MLX, the framework optimized for Apple Silicon’s unified memory.

Technical terms? Check the glossary.

Your sovereign SIEM's foundation, a hardened VPS outside the CLOUD Act

Mac Souverain — Fri, 12 Jun 2026 06:11:45 GMT

Before detecting anything, you need a place to install your SIEM. A machine. Not just any machine, not configured any way.

In the opening episode, we established why. GDPR already requires you to detect and notify a breach within 72 hours, NIS2 has widened the net, and it won’t stop there. American SaaS does the job but hands over your most sensitive logs on demand to the US government. It’s all very unfavorable to your interests, you’ll agree.

So, how to resolve this dilemma? The simple answer is, you build your own SIEM, GDPR and NIS2 compliant, on infrastructure you control entirely.

This article is the first brick. The foundation.

The rest of the series will stack on top of it. Wazuh in episode 2, agents in episode 3, network defense, email filter, execution control. If the foundation is shaky, the whole stack is shaky. A SIEM that monitors your park but runs on a machine itself compromised, it’s like a surveillance camera plugged into an open door.

The stack I recommend, I use daily. I’ll show you how to build your foundation, in order, with real commands. You can reproduce it today.

Choose the hoster, jurisdiction first

The first decision, and the most structuring one. Where your machine will live.

The temptation is to go for the cheapest or most well-known. AWS, Google Cloud, Azure. They’re excellent technically. But they’re all American nationality, and thus subject to the CLOUD Act, that wonderful 2018 law that allows US authorities to seize data from an American provider, wherever it’s stored in the world, including European datacenters.

Storing your security logs there is exactly the problem we’re trying to solve. So, what we’re looking for is a hoster whose headquarters, servers, and capital are not subject to this US exception.

Three criteria to really consider.

The jurisdiction of the headquarters. An European company without an American parent company is not subject to the CLOUD Act. Switzerland, Germany, France, etc. The nuance is, a hoster with an entity in the US exposes resources hosted in that entity to the CLOUD Act. The headquarters alone isn’t enough, you need to look where your data physically lives.
The location of the datacenters. Your logs need to stay on European servers, period. No transatlantic replication “for your availability”.
Price, last. A VPS to start a SIEM for an SME costs between 5 and 25 euros per month. At this level, the price difference between sovereign operators is marginal. You don’t choose your security hoster based on cents.

In practice, two names come up when crossing these criteria.

Infomaniak, Swiss hoster based in Geneva, owned 100% by its founders and employees, without external investment funds. Servers exclusively in Switzerland, under nLPD, the Swiss federal law on data protection entered into force in September 2023, aligned with GDPR and recognized by the European Commission’s adequacy decision.

No US subsidiary, not subject to the CLOUD Act by design, not part of the 5-eyes, therefore no extended cooperation with US intelligence. In Switzerland, all communication requests must go through justice, one of the most protective jurisdictions in the world.

Their datacenters are certified ISO 27001 and ISO 50001. It’s the operator I use, on their VPS Cloud range, but the entry-level VPS Lite can suffice to start.

Hetzner, German family-owned hoster founded in 1997, unbeatable performance/price ratio in Europe, with an ARM cloud range at 4.49 euros HT per month, around 5.40 euros TTC, at the time of writing. Excellent choice, with one condition. Hetzner opened datacenters in the US in 2021, then in Singapore in 2023. You need to provision your machine exclusively on their European sites, Falkenstein, Nuremberg, or Helsinki, to stay outside the CLOUD Act.

Two honest caveats in addition. Hetzner’s interface and support are only in English and German, and Hetzner sometimes suspends accounts deemed risky, without warning. Nothing blocking for a legitimate SIEM use, but good to know.

For this guide, I’m going with Infomaniak. The logic is the same at Hetzner, just the interface names change.

Read soon: Choosing your sovereign hoster, the complete comparison

Size the machine, not too much, not too little

Wazuh, which we’ll install in episode 2, isn’t lightweight. It comes with a manager, an indexer, and a dashboard. The indexer, in particular, loves RAM.

For an SME with up to fifty machines to monitor, the right starting point is three numbers.

4 vCPU, to absorb indexing and rule correlations without saturation.
8 Go of RAM, the bare minimum for the Wazuh indexer. Below that, it struggles or stops. I recommend 12 Go.
100 to 250 Go of SSD, depending on the log retention you want. The more months of history you keep, the more space you’ll need. NIS2 and GDPR think in months, plan ahead.

A VPS of this caliber runs around 15 to 30 euros per month with a sovereign operator. You can start smaller to test, but don’t go below 8 Go of RAM if you plan to run Wazuh on it for real.

For the system, choose a Linux distribution with long-term support. Ubuntu Server LTS or Debian stable. Both are well-documented, supported for years, and are what the Wazuh community tests first. I use Ubuntu Server LTS, that’s what I’ll use in the following commands.

The first contact, and the first hardening

You’ve just ordered your machine. The hoster sends you an IP address, a root ID, and a password. This is the most exposed moment in the entire life of the server, a root accessible via password on a public IP is exactly what bots scan all the time.

A precision before diving in. A server is administered via the command line, no graphical interface or mouse, the Terminal is your only cockpit. Each command in this guide is short and explained line by line.

The first connection session serves to close this door. In order.

Create a non-root user

Working as root daily is like driving without a seatbelt. The slightest command error executes with full privileges. We create a dedicated user, who can elevate their privileges when necessary via sudo.

adduser mack
usermod -aG sudo mack

The first adduser creates the account and asks for a password. The second adds the user to the sudo group, allowing them to execute admin commands by prefixing them with sudo. From now on, log in with this account, never as root directly.

Switch to key-based authentication

A password can be guessed, forced with a dictionary, stolen. A cryptographic key, no. We generate a key pair on your local machine, install the public part on the server, and disable password-based authentication completely.

On your Mac, in the Terminal:

ssh-keygen -t ed25519 -C "your-comment"
ssh-copy-id mack@IP_OF_THE_SERVER

The first command generates the key pair, in Ed25519, the modern, short, and solid algorithm. The second copies your public key to the server. Then test that you can log in without a password, ssh mack@IP_OF_THE_SERVER. If it works, we can cut off the rest.

Lock down SSH

This is where the attack surface really closes. We edit the SSH daemon’s configuration.

sudo nano /etc/ssh/sshd_config

Three lines to set, these are the three that matter.

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

PermitRootLogin no forbids direct root logins. PasswordAuthentication no disables passwords, only your key opens the door now. PubkeyAuthentication yes confirms that we accept keys.

Keep your current session open, restart the service, then test a new connection in a second window. An SSH config error, and you’re locked out of your own machine.

sudo systemctl restart ssh

A known trap with cloud images, Ubuntu often leaves a file /etc/ssh/sshd_config.d/50-cloud-init.conf containing PasswordAuthentication yes, which overrides your configuration. Check the actual applied value with sudo sshd -T | grep -i passwordauthentication, and if it comes back as yes, fix this file too.

Three commands, three config lines. You’ve just eliminated almost all automated attacks that target SSH. The bots that try root via password are now hitting a wall.

Enable automatic security updates

A server that hasn’t been patched is a vulnerable server, and no one connects every morning to launch updates manually. We automate security patches.

sudo apt update && sudo apt install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

The unattended-upgrades package automatically installs security updates published for your distribution, without touching the rest. Your known vulnerabilities close automatically, while you sleep.

The minimal attack surface, the real sovereign goal

The SSH hardening, that’s the basics. The level jump is here.

The guiding principle is one sentence. A port that doesn’t listen can’t be attacked. Each service exposed on a public IP is a door, and each door is a target. Maximum security isn’t the best lock on each door, it’s not having a door at all.

That’s exactly the logic we saw for the Secure Enclave. The most secure component is the one that refuses access, not the one that defends it well.

The firewall, closed by default

On Ubuntu, the firewall is managed with ufw. The right posture is the inverse, we block everything, then open only what’s necessary.

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw enable

default deny incoming refuses all incoming connections. default allow outgoing lets your machine join the outside world, for updates, for example. We only open port 22, SSH, the bare minimum to administer the machine. And we enable.

At this point, your server presents only one SSH door per key. That’s already a profile radically more discreet than 90% of production VPS.

Tailscale, and the public IP disappears

We can do better. Instead of opening SSH on the public IP, even via key, we remove it entirely from internet view and expose it only on a private, encrypted network.

That’s the role of Tailscale. Tailscale creates a private mesh between your devices, over WireGuard, the modern tunneling protocol. Your machines see each other via private addresses, like they’re on the same local network, even if they’re scattered between a Swiss datacenter, your office, and your home. The rest of the internet, meanwhile, sees nothing.

Here’s the concrete flow. You install Tailscale on the server and on your Mac. Both join your private network. Your Mac gets a Tailscale address, the server does too. You log in to the server via its Tailscale address, not its public IP. And you close port 22 on the public IP. To reach SSH, you have to already be a member of your private network. An attacker on the internet can’t even see that the port exists.

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

The command displays a link, you open it in your browser, authenticate the machine, it joins your network. Repeat on your Mac. Retrieve the server’s Tailscale address:

tailscale ip -4

Test the SSH connection via this private address. Once it works, we close port 22 on the public IP:

sudo ufw delete allow 22/tcp
sudo ufw allow in on tailscale0 to any port 22 proto tcp

The first line removes the SSH opening on all interfaces. The second reopens it only on the tailscale0 interface, your private network. SSH only listens on the encrypted mesh.

The result is a machine with only one admin door, invisible from the internet. Not locked, invisible. A port scan on your public IP reveals nothing exploitable.

For the rest of the series, that’s also how your Wazuh agents will send their logs to the server, never through the open internet. The network foundation we’re putting in place today serves the whole stack.

And the services that must remain public?

Not everything can live behind the private network. If your server hosts a website or a service that needs to be reachable by anyone, that service has to listen on the public IP. It’s inevitable.

The rule, then, isn’t “zero public ports” but “zero unnecessary public ports”. You open exactly what the service requires, nothing more. A website, that’s port 443 in HTTPS, and port 80 while renewing certificates. Nothing else. Everything else, administration, databases, internal dashboards, stays on Tailscale.

For our SIEM foundation, at this point, the simple answer is no public services. The server exposes nothing to the world. Wazuh, which we’ll install later, lives entirely behind Tailscale, accessible only to you.

The backups, encrypted off-site

A hardened server isn’t an immortal server. A datacenter can burn down, as we saw with OVH Strasbourg in March 2021, clients without backups lost everything. A ransomware can still pass on one of your production machines. A finger slip on a wrong command can erase a database.

The rule is non-negotiable. Your backups live elsewhere than on the machine they protect, and they’re encrypted before they leave. Encrypted by you, on your machine, before sending. Not encrypted by the storage provider, by you. That way, even the storage provider can’t read what it’s storing.

The tool I use is Kopia. Open source, fast, and it does exactly what we want, client-side encryption before transfer, deduplication to not explode your storage volume, and sending to an S3-compatible storage.

And the off-site storage, I take it with Swiss Backup, Infomaniak’s backup service. Same logic of sovereignty as for the VPS, Swiss servers, not subject to the CLOUD Act, and an S3 endpoint that Kopia consumes directly.

The concrete flow. Kopia runs on your server. Once a day, or several times, it takes a snapshot of the folders that matter, your system configuration, your Wazuh data, your logs.

It encrypts this snapshot locally, with a key that only you hold. Then it sends it to Swiss Backup. The day the server dies, you provision a new machine, reinstall Kopia, point it to the remote repository with your key, and restore.

curl -s https://kopia.io/signing-key | sudo gpg --dearmor -o /usr/share/keyrings/kopia-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/kopia-keyring.gpg] http://packages.kopia.io/apt/ stable main" | sudo tee /etc/apt/sources.list.d/kopia.list
sudo apt update && sudo apt install kopia
kopia repository create s3 \
  --bucket=YOUR_BUCKET \
  --endpoint=s3.swiss-backup.infomaniak.com \
  --access-key=YOUR_KEY \
  --secret-access-key=YOUR_SECRET

The first three lines install Kopia from its official repository. The last command creates the encrypted repository on the remote storage, using the exact endpoint displayed in your Swiss Backup console, it varies depending on the cluster you’re assigned. Kopia asks for a passphrase when creating the repository, that’s the key to encrypt all your backups. Note it down somewhere other than on the server. If you lose it, your backups are permanently unreadable, including to you. That’s the price of client-side encryption, and that’s exactly what we want.

Then automate. We create a daily snapshot of the critical folders, then schedule it with a cron job.

kopia snapshot create /etc /home /var/log

This command captures the current state of the three folders. You schedule it to run every night, and occasionally check that your snapshots are there with kopia snapshot list. A backup you don’t test is not a backup, it’s a hope. So we’ll need to plan a test restore of your data every quarter.

This SIEM foundation will serve the rest of the series. Every brick we add, Wazuh and its data, the rules you calibrate, will be captured in the same encrypted snapshot, off-site, ready for the day you need it.

In summary

The foundation is four gestures that build on each other.

You’ve chosen a hoster whose jurisdiction protects you, not just whose datacenter is in Europe. You’ve hardened access, non-root user, key-based authentication, root forbidden, automatic updates. You’ve reduced the attack surface to nothing, closed firewall by default, admin behind a private encrypted network, no unnecessary public ports. And you’ve put encrypted backups off-site, unreadable to anyone without your key, ready for the day when.

None of these steps are complicated. Together, they turn a rented machine into a fortress you control. It’s the exact opposite of what you sign up for with an American SaaS, where the data is yours but the infrastructure and jurisdiction aren’t.

An afternoon’s work. Not a weekend.

The foundation is in place. In episode 2, we fill the vault. Wazuh all-in-one, manager, indexer, and dashboard on this single node. The functional equivalent of a Splunk, for the price of the VPS you’ve just built. Your SIEM starts to exist.

Series reminder

Seven episodes to build your sovereign security plumbing, brick by brick.

Episode 0, the bedrock of the series. Why an SME needs a sovereign SIEM, NIS2, GDPR, and the cost of doing nothing.
Episode 1, the foundation. The hardened VPS outside the CLOUD Act. You’ve just read it.
Episode 2, Wazuh all-in-one. Manager, indexer, and dashboard on a single node.
Episode 3, agents everywhere. Deployment on your servers, Macs, and Windows machines.
Episode 4, community network defense. Block known attackers before they arrive.
Episode 5, the mail filter. Anti-spam and anti-phishing in front of your mail server.
Episode 6, Mac execution control. Decide which applications have the right to launch.
Episode 7, alerting and total cost. Calibrated notifications and honest financial breakdown against SaaS.

Technical terms? Check the glossary.

Build your sovereign SIEM for SMEs, compliant with GDPR/NIS2 without CLOUD Act

Mac Souverain — Fri, 05 Jun 2026 12:00:56 GMT

You don’t have a SIEM. You tell yourself it’s not for you, that your SME is too small or outside a regulated sector, so under the radar of the big cyber obligations. You’re wrong on two counts.

Now, GDPR. Since 2018, any company that processes personal data must notify the CNIL of a breach within 72 hours. That’s Article 33. Not a recommendation, an obligation. Notifying within 72 hours means you know something happened, that you can characterise it, that you have the logs to trace the chain back. Without a system that centralises your logs and raises alerts, this obligation is unenforceable. You’re in breach the first time a ransomware gets through.

Tomorrow, the widening. NIS2 has just multiplied by thirty the number of French entities subject to reinforced cyber obligations, from 500 to around 15,000. DORA has applied since January 2025 to the extended financial sector, subcontractors included. The Cyber Resilience Act applies fully from December 2027 to any product with a digital component sold in the EU. NIS3 isn’t voted on yet, the indicative timeline aims for the end of 2027. But the trajectory is legible, every two to three years the net widens. Betting your SME stays out of scope in 2028 or 2029 is betting against Brussels and against the GDPR case law that has done nothing but harden.

The word that keeps coming back in all these texts is SIEM, for Security Information and Event Management, centralised management of security events. They never name it, but they make it impossible to avoid. Detecting an incident, keeping exploitable logs, notifying the regulator within short deadlines, those are the functions of a SIEM.

And what is a SIEM, concretely? Picture the CCTV of your shop, but for your IT. Every server, every firewall, every workstation, every mailbox constantly produces a log of what happens on it. Who logged in, at what time, from where, which file was opened, which process started.

A SIEM is the system that brings all these logs to one place, keeps them for several months, and raises an alert when it detects suspicious behaviour.

An account that logs in at 3 in the morning from Pakistan, ten thousand files encrypted in two minutes, a burst of failed passwords on the director’s account, these are signals a human will never catch with the naked eye on a fleet of fifty machines.

The SIEM sees them, cross-references them, and warns you. Behind this consultant’s acronym hides a very concrete assembly, which we take apart further down in this article.

The problem is what’s being sold to you today under that name. Splunk, Microsoft Sentinel, CrowdStrike. At a modest SME’s entry ticket the prices look affordable, but the bill climbs with every gigabyte and every seat, and we do the full accounting at the end of the series. And the price isn’t even the worst of it. These products store your incident logs in a jurisdiction that isn’t yours, under the CLOUD Act. The real question is who holds your most sensitive data.

There’s a third path. The sovereign one. It’s the path of this series.

NIS2 in five minutes, and why it concerns you even outside the scope

NIS2 is the European directive on the security of networks and information systems, replacing NIS1. NIS1 covered around 500 French entities. NIS2 covers around 15,000, spread across eighteen sectors. Health, energy, transport, digital, financial services, agri-food, waste, manufacturing. If your company exceeds 50 employees or 10 million euros in revenue in one of these sectors, you’re directly concerned. Probably as an “important entity”, sometimes as an “essential entity” depending on your size and criticality.

If you’re smaller or outside a listed sector, you’re not off the hook for all that. Two mechanisms catch you. First the supply chain, Article 21 requires NIS2 entities to assess the cyber-resilience of their subcontractors. If you sell service or software to a 60-person SME in health or finance, it’s going to ask you for your proof. No SIEM, no contract. Then the regulatory trajectory itself, NIS3 is in preparation at the Commission, the scope always widens from one revision to the next.

The heart of the mechanism is Article 21. Ten categories of minimum measures, risk analysis, incident management, logging, continuity, training, encryption, access control, supply chain security. And the notification obligation, in three steps, early warning within 24 hours, structured notification within 72 hours, final report within 30 days.

The triptych holds for NIS2 as for GDPR, without a detection and logging foundation, the obligation is unenforceable.

Article 20 adds the detail that changes everything for the director. Liability falls on the natural person who runs the company. Not on the IT manager, nor on the provider. On you.

On the sanctions side, it’s calibrated to hurt. Essential entity, up to 10 million euros or 2% of worldwide revenue, whichever is higher. Important entity, up to 7 million euros or 1.4% of worldwide revenue. For an SME with 30 million in revenue, we’re talking a maximum sanction of several hundred thousand euros.

The law of 30 April 2025 transposes NIS2 into French law. The implementing decrees and the exact scope of the entities concerned are being specified over the course of 2026. As long as it’s fuzzy you tell yourself you have time, but the directive already applies, the case law will be built on the first disputes. The question is when, not if.

We already saw in a previous article how NIS2 contradicts CSAR on encryption. Here, we look at the other obligation, the one that becomes concrete for your infrastructure, detect, log, notify.

You have three options, and two of them are bad

Option 1, US SaaS

Splunk, Microsoft Sentinel, CrowdStrike, Datadog, Elastic Cloud. They work. They’re mature. And at a modest SME’s entry price, they’re not out of reach. The trap is elsewhere.

Microsoft Sentinel charges around $4.30 per gigabyte ingested in the East US region, in the simplified billing model that combines Log Analytics ingestion and Sentinel analytics. CrowdStrike Falcon charges per endpoint, between $60 and $185 per seat per year depending on the tier, Go, Pro, Enterprise or Complete. Splunk is more opaque, the vendor doesn’t publish its prices, but serious secondary sources converge around $8,000 to $12,500 per year for an entry ticket of 5 gigabytes of logs per day, licence only, in Cloud or self-hosted Enterprise.

Take a 50-employee SME that generates five gigabytes of logs per day. On Microsoft Sentinel, around $7,800 per year. On CrowdStrike Falcon Pro for 50 endpoints, around $5,000 per year. On Splunk Cloud at entry, around $8,000 per year. Let’s be honest, $13,000 per year for Sentinel and CrowdStrike combined, on an SME with $10 million in revenue, is 0.13% of turnover. The entry cost isn’t the obstacle.

The obstacle is what you sign up for at the same time. Your logs go to the United States, or to a European subsidiary of an American company. The CLOUD Act, passed in 2018, lets US authorities requisition this data from the provider, even when it’s physically stored in Europe. Microsoft Ireland, Splunk Cloud, CrowdStrike, all are subject to it through their parent company.

And your incident logs aren’t just any data. They’re the complete fingerprints of your network, the usernames, the application flows, the internal behaviours, the vulnerabilities exposed at the moment of the attack. The most sensitive material your information system produces. Handing it to a provider requisitionable by a foreign jurisdiction is a real operational risk.

The Data Privacy Framework, the EU-US legal bridge, survived first instance before the EU General Court in September 2025. It’s on appeal before the CJEU since 31 October 2025. The CNIL, in its February 2025 decision on health hosting, is clear, the only recognised marker for materialising a sovereign cloud remains the SecNumCloud qualification. None of the three SaaS providers cited has it.

One last point. The reasonable entry cost is today. The billing mechanism gets worse as you grow. Every additional gigabyte ingested is charged, every additional endpoint too. At 50 gigabytes of logs per day, the Sentinel ticket climbs above $78,000 per year, Splunk rises in proportion depending on the licence mode. You sign a modest entry price, you also sign a tariff lock-in that closes in as your SIEM sees wider and deeper.

Conclusion, you pay a reasonable price for the plumbing today, by handing the most strategic data in your information system to a jurisdiction that isn’t yours, in an unfavourable legal framework, with a meter running against you at every extension of scope.

Option 2, do nothing

It’s tempting. It’s the most common strategy among SMEs, whether or not they’re in the NIS2 scope. Wait. See. Hope.

The calculation is wrong on three fronts. GDPR today, the CNIL has already sanctioned SMEs for failure to notify, the absence of any detection means is an aggravating factor. NIS2 tomorrow if you enter through the supply chain or through a revision, the maximum sanction for an essential entity exceeds GDPR’s, the director’s personal liability exists in black and white. Ransomware any time, encryption of production, ransom, loss of operations, that’s another order of magnitude than getting into compliance.

Doing nothing isn’t saving. It’s postponing, at the risk of worsening the final bill.

Option 3, sovereign self-hosted

You build your SIEM with mature open-source bricks, deployed on an infrastructure you control. Four bricks, four complementary roles.

Wazuh, it’s the brain of the setup, the central platform that brings all the logs to one place, stores them, analyses them and raises the alerts. It’s your “home-made Splunk”.
CrowdSec, it’s the bouncer at the door. A community network defence that automatically blocks the IP addresses already flagged as attackers by the other users of the network. When a bot scans a thousand sites before yours, it’s blacklisted before it reaches you.
Rspamd, it’s the filter in front of your mail server. It intercepts spam and phishing attempts before they reach your employees’ inboxes. Mail remains the number one intrusion vector for SMEs, that’s where prevention pays off most.
Santa, it’s the execution controller on your Macs. It decides which applications are allowed to start on each machine, according to an allowlist you build. A ransomware downloaded by mistake can’t run, because it isn’t signed by a vendor you’ve approved. It’s the brick that turns an everyday Mac into a hardened workstation, without the user having to change their habits.

None of these bricks is experimental. Wazuh is used by Fortune 100 companies. CrowdSec, a French company founded in 2019, aggregates 10 million signals a day, shared by more than 70,000 users across 190 countries. Rspamd powers Mailcow, Zimbra, Mailu, which set the reference. Santa, originally developed at Google and now maintained by North Pole Security, runs in production at Figma.

The cost, it’s a correctly sized VPS, the installation time, and an internal competence you build. Not zero, but nowhere near the figures above.

What a SIEM really is, for someone who doesn’t do blue team

The word is scary. It smells of black screens, 24/7 teams and analysts speaking a dialect your IT manager doesn’t understand. Once demystified, it’s simpler.

A SIEM is plumbing. Not a product, an assembly. Four functions that chain together:

Collect the logs from your equipment, servers, firewalls, workstations, applications, mailboxes. Everything that produces a log, you bring to one place.
Centralise and keep these logs in an exploitable format, with a retention that lets you investigate an incident going back several months.
Detect abnormal behaviours. An account logging in at 3 in the morning from an unusual country, a burst of failed authentications, a process that modifies 10,000 files in one minute.
Alert and keep the trace, for your ANSSI notification within 24 hours, and for your final report within 30 days.

That’s it. No magic. A system that sees, that remembers, and that shouts when something’s wrong.

The hard work isn’t the technology, it’s the adjustment. Which rules you enable, which thresholds you calibrate, who you send the alert to, how you respond. It’s the same thing on Splunk or on Wazuh. And it’s that internal competence you’re going to build across this series.

In short

Building your SIEM in 2026 pays you on two horizons.

Short term, it’s operational security. A ransomware detected in hours instead of weeks, an exfiltration intercepted before the ransom, a GDPR breach you can characterise and notify within the deadlines. That ROI depends on no text that isn’t yet voted, it’s immediate.

Medium term, it’s amortised compliance. You build the infrastructure and the internal competence before the obligation lands on your head. Your competitors will build it under pressure, in a hurry, at three times the price of a flash-mission consultant. You’ll have taken a five-year lead on them for the price of a few weekends spread over a quarter.

US SaaS does the job and isn’t out of price on the entry ticket. It just delivers your most strategic data into an unfavourable jurisdiction, and locks you into a model where every extra gigabyte is charged. Self-hosting demands an initial time investment. In the end, you’re master of the data, of the marginal cost and of the compliance schedule. Real sovereignty against a little of your time, which we’ll make a point of optimising across our articles.

Seven episodes to build your plumbing

It’s the stack I use in production. Not a blogger’s fantasy, an infrastructure that runs day to day, that detects, that logs, that notifies. Seven episodes, seven bricks:

Episode 1, the foundation. A hardened VPS, on a European host outside American reach. Choice of operator, base configuration, minimal attack surface, encrypted off-site backups.
Episode 2, Wazuh all-in-one. Installing the manager, the indexer, the dashboard on a single node. Hardening, first dashboards. The functional equivalent of a Splunk for the price of a VPS.
Episode 3, agents everywhere. Deploying Wazuh agents on your servers, Macs and Windows. Collecting system logs, security events, file activity. The moment your SIEM starts to see.
Episode 4, CrowdSec on the front line. The community network defence that blocks known attackers before they reach your services. Wazuh integration, signal sharing.
Episode 5, Rspamd for the mail. The anti-spam and anti-phishing filter that plugs in front of your mail server, or integrates with your existing solution. Phishing detection, logging into Wazuh.
Episode 6, Santa on the Macs. Execution control on Apple machines. North Pole Security fork, the project actively maintained since Google handed it over in 2024. Progressive lockdown, Wazuh integration.
Episode 7, alerting and total cost. Calibrated notifications, escalation, honest financial breakdown, episode-by-episode comparison with what the equivalent SaaS would have cost.

The links light up as the episodes publish, come back and plug into the new ones as they come out.

Each episode is standalone. You can stop at 3 and already have covered the essentials of NIS2. You can push to 7 and have a stack with nothing to envy in those of large companies.

Apple Intelligence: What's Really Leaving Your Mac

Mac Souverain — Thu, 28 May 2026 07:48:57 GMT

Update of June 21, 2026. Since June 8, 2026, PCC no longer runs solely on Apple silicon: for the heaviest queries (agentic, complex reasoning), Apple switches to Google Cloud hardware, NVIDIA GPU, Intel CPU, and Titan chip. Apple swears that the five guarantees hold, that it keeps software control, and that Google sees nothing in the clear. Perhaps. But the “all stays with Apple” argument for the general public has just fallen: it’s now also Google iron under Apple guarantees.

You’ve updated your Mac. You’ve accepted the TOS without reading (like everyone else). A few weeks later, you realize that the “Apple Intelligence” toggle is on, when you had turned it off. It’s not a hallucination: since macOS 15.3 released on January 27, 2025, Apple Intelligence has switched from opt-in to opt-out. And some users who had turned it off found it turned back on after 15.3.1, a bug confirmed by MacRumors and 9to5Mac, inconsistent from one device to another. Not a systematic rule, but frequent enough to check after each update.

It’s time to understand what happens when you click “Summarize” on a long email. Because between your Neural Engine and a California data center, there are three processing layers. Only one stays really on your machine.

Why this question is not harmless

Apple sells Apple Intelligence as an IA “privacy-first”. The slogan is everywhere on the product site: aware of your personal information without collecting your personal information. It’s technically true for part of the perimeter, and technically false for the rest.

A generative AI, by construction, needs calculation. When the model running on your Mac isn’t enough, the request goes out. Either to Apple servers or those of OpenAI. In both cases, your text leaves your machine. The question isn’t whether it goes out. It’s where, under what guarantees, and how Apple informs you (spoiler: badly).

Layer 1: the local model, what stays really on your machine

On Apple Silicon (M1 and later), Apple runs a foundation model of about 3.18 billion parameters. Quantified 2 bits per weight via Quantization-Aware-Training, memory footprint of about 1 Go, shared KV-cache that saves 37.5% RAM. The calculation happens on the Neural Engine, the GPU, and the CPU of the chip, never on a server.

In concrete terms, here’s what stays 100% local:

Writing Tools short version: Proofread, Rewrite, Summarize on short texts
Smart Reply in Mail and Messages
Notification summaries and Priority Notifications
Short Mail summaries in the inbox list
Genmoji (generation of custom emoji)
Image Playground (Animation, Illustration, Sketch)
Image Wand in Notes
Basic Siri (understanding, type-to-Siri)
Clean Up Photos

For these uses, your text does not leave the Apple Silicon. No logs, no server, no content telemetry. That’s the honest perimeter of Apple’s promise, and it’s real.

The problem starts when you ask for something else. Long summary of an 80-message Mail thread, generated text composition, multi-step Siri reasoning: your Mac knows it can’t handle the load. It switches. And Apple doesn’t display any indicator to signal it.

Layer 2: Private Cloud Compute, the California enclave

This is Apple’s marketing strong point. PCC runs on custom-silicon Apple in their data centers, with five technical guarantees highlighted in the Security Research doc:

Stateless computation: your text is used to respond, never stored after the request.
Enforceable guarantees: the protections are technically applied, not contractually promised. An Apple admin can’t disable the mechanism.
No privileged runtime access: no remote shell, no interactive debugging. Apple can’t extract your data, even voluntarily.
Non-targetability: an attacker can’t route your request to a compromised specific node. Request diffusion to nodes is random and attested.
Verifiable transparency: each production build published in a cryptographically append-only log, binary images available for external inspection for 90 days.

Apple pushed its PCC server code on GitHub, opened a research environment to external researchers, and put up a $1 million bug bounty. As of today, it’s the most auditable cloud IA stack on the market.

Now the nuances, because there are some.

Trail of Bits, in its June 14, 2024 analysis, points out a point that Apple marketing glosses over: “the data is decrypted on Apple’s server”. PCC is not homomorphic encryption (the tech that calculates a model on encrypted data without ever decrypting it). It’s a hardened enclave, signed, attested, but your text is indeed decrypted on the Apple side during the calculation. Security relies on the integrity of the enclave and the signing of the binaries, not on cryptographic magic. Apple is honest about this in the tech doc. The consumer slogan, however, leaves room for misunderstanding.

Second nuance, more uncomfortable. Matthew Green, cryptographer at Johns Hopkins, on Mastodon in June 2024: “Apple does not have explicit plans to announce when your data is going off-device for Private Compute, and you won’t opt into this or necessarily even be told it’s happening”. Translation: you don’t know if the summary of your mail stayed on your M2 or if it made a round trip to California. No visual indicator, no notification, no user-side journal. Apple’s transparency is cryptographically verifiable but visually invisible.

Layer 3: ChatGPT, the opt-in and its trap

ChatGPT is grafted onto Apple Intelligence since macOS 15.2. Turned off by default, activatable explicitly in Apple Intelligence & Siri → Extensions → ChatGPT. When you turn it on, Apple adds two protections over the standard OpenAI contract:

Your IP is masked by the Apple relay (verbatim Apple Legal: “your IP address is obscured from ChatGPT”). Approximate location passed, for legal compliance and anti-fraud.
No-logs and no-training on OpenAI’s side, provided you haven’t linked your OpenAI account. Apple Legal: OpenAI “must process your information solely for the purpose of fulfilling your request”, “must not store your information”, “must not use your information to improve or train its models”.

Read the conditional carefully. If you link any OpenAI account (free, Plus, Pro, Team) to retrieve your history or access GPT-5, you immediately opt out of Apple’s contract and fall back under OpenAI’s standard TOS. Logs, conversation history, potential training, all under US jurisdiction. Apple mentions this in the legal text, in small print, after three paragraphs. Most users link their account without realizing they’ve just turned off the protection that made them choose Apple.

Second detail. The “Confirm ChatGPT Requests” toggle is on by default: Siri asks for confirmation before sending the text. You can turn it off. But especially, if you start your voice request with “Ask ChatGPT…”, confirmation is bypassed. It’s a documented shortcut on Apple’s side, that circumvents the only visible safeguard of the device. Photos and files keep confirmation, they do, in all cases.

The four toggles to check

Four paths to know on Sequoia 15.x and Tahoe 26. The English titles are guaranteed (tested by Apple Support on US Macs), the French ones are the titles you’ll likely see, to be confirmed on your Mac.

1. The master Apple Intelligence System Settings → Apple Intelligence & Siri (toggle at the top of the panel). Default state since macOS 15.3: ON on compatible Macs. Documented cases of reactivation on 15.3.1 (bug, not design). Rare afterwards, but check after each update. Turn off if you want nothing, really nothing.

2. ChatGPT master System Settings → Apple Intelligence & Siri → Extensions → ChatGPT → Use ChatGPT. Default state: OFF. Activate only if you want it, and especially: don’t link your OpenAI account.

3. Confirm ChatGPT Requests System Settings → Apple Intelligence & Siri → Extensions → ChatGPT → Confirm ChatGPT Requests. Default state: ON. Leave it on. The confirmation friction is your only visual indicator that a request is going off your Mac.

4. Improve Siri & Dictation System Settings → Privacy & Security → Analytics & Improvements → Improve Siri & Dictation. Default state: OFF. Check that it stayed OFF. It decides if Apple stores audio snippets of your Siri interactions for human review. Random ID, hourly rotation, no Apple ID link, they insist. You choose to trust them or not.

Apple, Microsoft, Google: who does what

Five criteria that matter to someone wondering about sovereignty. Vendor by vendor verdict.

Apple Intelligence. Local by default, yes: 3B on-device model, explicit PCC switch for heavy queries. Public cryptographic attestation, yes: transparency log, dedicated research environment (VRE), server code published on GitHub. Cloud opt-in, half and half: implicit and invisible PCC, explicit and confirmed ChatGPT requests. Third-party LLM integrated, OpenAI ChatGPT, opt-in, OFF by default, no-logs as long as you don’t link your OpenAI account. Server jurisdiction, USA, Apple custom-silicon data centers.

Microsoft Copilot+/Recall. Local by default, partial: Recall makes its snapshots locally and never sends them to the cloud, Copilot general runs in Azure. Public attestation, no: local VBS encryption plus TPM, no opposing auditable server. Cloud opt-in, depends on the feature: Recall purely local, Copilot general cloud by design, the user doesn’t always distinguish which triggers what. Third-party LLM integrated, Azure OpenAI GPT-4, commercial integration without separate opt-in. Server jurisdiction, USA plus global Azure regions.

Google Gemini. Local by default, no: cloud Google by default, Gemini Nano local exists but remains limited to high-end Pixel devices. Public attestation, no. Cloud opt-in, the opposite: cloud by default, partial opt-out via Activity, and you lose features along the way. Third-party LLM integrated, none, Google’s stack locked down. Server jurisdiction, EEE/Switzerland via Google Ireland for EU accounts, rest of the world via Google LLC (USA).

A quick read: on this specific dossier, Apple does better. Recall version 2025 is solid locally but remains an attack vector on shared devices (Kevin Beaumont has documented it repeatedly). Gemini keeps a subset of chats for up to three years for human review, even when you turn off activity. Apple is the only one to publish its server code and pay $1 million to have it broken.

Apple spent $1 million to have its code broken. The others spent $1 million on TV spots. That doesn’t make PCC an E2EE. It makes it the least opaque cloud IA option on the market in 2026.

Mack’s verdict

Apple has built the most auditable cloud IA architecture on the mass market. That’s a fact. Trail of Bits, Matthew Green, and Schneier all recognize it, each in their own way, while pointing out what’s wrong.

What’s wrong is three UX decisions that betray a marketing intent superior to privacy intent: the opt-out by default since 15.3, the complete absence of a visual indicator when a request switches to PCC, and the silent OpenAI account link trap. None of these three points is a bug. They’re choices.

What you can reasonably do: turn off the master if you don’t need it, keep the ChatGPT confirmation toggle on if you use it, never link your OpenAI account, check Improve Siri & Dictation after each major update. That’s five minutes of settings, to be redone two or three times a year.

Also read: The cloud, it’s someone else’s computer, Privacy macOS: the settings to change immediately, and Convergence of digital freedoms.

Sources

Apple, primary sources

Apple Machine Learning Research, Introducing Apple’s On-Device and Server Foundation Models, official publication of the on-device model specifications (June 10, 2024).
Apple Machine Learning Research, Foundation Models Tech Report 2025 and arXiv 2507.13575, technical details of the 2-bit QAT, PT-MoE, 15 languages (July 17, 2025).
Apple Security Research, Private Cloud Compute: A new frontier for AI privacy in the cloud and Security research on PCC, the complete PCC doc and the bug bounty.
Apple Legal, ChatGPT Extension and Privacy and Apple Support, Use ChatGPT with Apple Intelligence on Mac, reference source for IP masking and conditional no-logs.

Independent analyses

Trail of Bits, PCC: a bold step forward, not without flaws, recognized security firm, the most cited technical analysis of PCC’s limits (“data decrypted on Apple’s server”).
Matthew Green, Mastodon/X thread on PCC, cryptographer at Johns Hopkins University, on the absence of a visual indicator when a request switches to PCC.
Kevin Beaumont (DoublePulsar), Microsoft Recall privacy implications, Windows security expert, on the residual risks of Recall version 2025.
MacRumors, macOS 15.3 enables Apple Intelligence automatically, coverage of the opt-in to opt-out switch (January 21, 2025).
IronCore Labs, Privacy Guide to Apple Intelligence with ChatGPT, for the OpenAI account link trap.

Comparison with competing IAs

Microsoft Support, Privacy and control over your Recall experience, Microsoft’s official Recall doc after the April 2025 relaunch.
Google Gemini Apps Privacy Hub, Google’s doc on retention, activity, and human review.

Your Mac was patched by XProtect without your knowledge, it's for your own good

Mac Souverain — Tue, 19 May 2026 07:25:30 GMT

While you were sleeping, on the evening of May 11th, 170 software packages, used by half of the web, became malicious in just six minutes. The next day, Apple pushed an XProtect signature onto your Mac, without telling you.

The two events are likely connected. However, you’ll never know for sure. This incident has a name, TanStack. The mechanism that may have reacted on your Mac is called XProtect. You didn’t see anything, neither did I. Apple makes sure of that.

Welcome to the silent defense system of your Mac.

The TanStack Incident in 30 Seconds

On the evening of May 11th, 2026, the TanStack ecosystem, an ultra-popular JavaScript toolkit used by millions of developers (including those from OpenAI, Netflix, Shopify), was compromised. In six minutes, 170 packages were released with malicious versions. The most visible one, react-router, is downloaded 12 million times a week. In other words, a significant portion of the web that updates this week is getting infected without knowing it.

The malware is called Mini Shai-Hulud, a variant of the npm worm that has been around since 2024. Its target is whatever is on the developer’s Mac: passwords, cloud access keys, GitHub tokens, session files. On macOS, it installs itself discreetly and relaunches every time a session is opened. Clean, professional.

The worrying detail is the vector. The attacker didn’t steal any passwords or exploit any code flaws. They just submitted a false contribution to the open-source TanStack project, exploiting an imprudent automation system configuration.

Any contribution was executed with the real publication rights. A malicious pull request was enough to retrieve the signature token and publish 170 packages under the legitimate identity of the project. On npm’s side, everything seemed normal, signed, and verified. Stamped by TanStack itself.

OpenAI was affected by association, via one of its dependencies. Officially, there’s no proof of any product or user data compromise. But they still rotated all their applicative signature keys on macOS, iOS, Windows, and Android, and republished all their apps under new certificates.

You don’t do that when everything’s fine.

Apple reacted the next day. No communiqué, no notification, no tab in Settings. An XProtect signature was silently pushed. Macs picked it up over the hours, one by one, without telling anyone.

XProtect, Apple’s Silent Antivirus

XProtect is macOS’s integrated antivirus. It’s been there since Snow Leopard, and most users don’t even know it exists. That’s by design.

It works in two parts. The first is the signature engine: a file that macOS consults before executing a downloaded app to check if it matches a known malware. The second is XProtect Remediator, XPR, a scanner that runs in the background and inspects your disk for threats that are already installed. When it finds one, it neutralizes it.

Signatures are pushed by Apple via CloudKit, the same silent pipeline that synchronizes your iCloud photos and keychain. When a significant malware emerges, Apple compiles a signature, signs it, deposits it on CloudKit. Your Mac picks it up during the next check, usually within 24 to 72 hours.

No notification. No restart. No “your Mac has been updated” message. Apple made an editorial choice not to alarm users. The downside is that you have no way of knowing, at a glance, if you’re properly patched for the recent incident.

That’s where it gets interesting.

The Push 5344, May 12th, the day after TanStack

The XProtect version published on May 12th, 2026, is called 5344. The previous one, 5342, was from May 5th. Perfect temporal match with TanStack, one day later.

Except Apple never publicly documents the content of an XProtect signature. Howard Oakley, who dissects each release on eclecticlight.co, notes on 5344 “some adjustments on known malware families”. No TanStack or Shai-Hulud signature. Nothing officially saying “this is the response to yesterday’s incident”.

Coincidence or targeted reaction? Apple isn’t saying. That’s precisely what justifies looking into it.

Check in 30 Seconds if Your Mac is Patched

On macOS 15 Sequoia and macOS 26 Tahoe, Apple moved XProtect to a new location and provides a native command. That’s the recommended way. On macOS 14 Sonoma and earlier, the old location is still valid. I’ll give you both.

1. The XProtect signature version

On Sequoia and Tahoe:

sudo xprotect version

You’ll get a number like 5344 or 5347. That’s the signature base. The higher the number, the more recent it is.

On Sonoma and earlier:

defaults read /Library/Apple/System/Library/CoreServices/XProtect.bundle/Contents/Info CFBundleShortVersionString

The old path still exists on Sequoia and Tahoe, but macOS doesn’t consult it first anymore. You can read it and get an outdated version while sudo xprotect version gives you the real one. That’s exactly the kind of trap that makes you think your Mac is behind when it’s not.

2. The XProtect Remediator version

defaults read /Library/Apple/System/Library/CoreServices/XProtect.app/Contents/Info CFBundleShortVersionString

You’ll get a number like 157. That’s the scanner itself, updated much less often than the signatures.

3. The installation history

system_profiler SPInstallHistoryDataType | grep -A 2 -i xprotect

You’ll see all the XProtect versions installed with their dates. Great for checking if your Mac isn’t stuck on an old base because CloudKit has a problem.

To compare your version with what Apple publishes in real-time, the public tracker on Howard Oakley’s eclecticlight.co keeps the list up-to-date. Oakley is a British engineer who’s been dissecting macOS for fifteen years. He’s the reference on the subject.

And if your Mac is behind, force the check:

sudo xprotect update

On Sonoma and earlier, the old command sudo softwareupdate --background-critical still works.

At the time of publishing, the latest version is 5344, on May 12th, 2026. If your Mac shows less, your CloudKit channel is slow.

The Sovereign Downside

XProtect is a black box signed by Cupertino. You don’t know which signatures are pushed, what telemetry is sent back, or who decides that a binary is malicious. Apple decides, Apple pushes, your machine executes.

The mechanism is useful, very useful even. Blocking known malwares before they execute is the base of modern defense, and doing it without bothering you will prevent you from disabling it when you’re fed up with that rognutudju!! pop-up (look it up, if you’re under 50, you won’t get the reference).

The three commands above give you a minimal right to look into what your OS does without asking. It’s a small step towards sovereignty, not taking control back, just knowing.

The difference between a passive user and a sovereign user isn’t just in the tools they use. It’s also in the questions they ask. What version do I have? When was it pushed? What’s in it?

Apple answers the first two with three Terminal lines. On the third, they stay silent. It’s Howard Oakley who dissects the content afterwards and publishes the diffs on eclecticlight.co. You’ll never know directly what Apple has stamped as malicious that night.

Every month, I still check the XProtect versions on my Macs. Nothing heroic, just a habit. The day CloudKit’s channel screws up, I’ll have a reference point.

Read also: The macOS settings to change immediately

In Summary

XProtect is useful, silent, and out of your control. The topic is knowing that it exists, knowing the three commands that tell you where you stand, and understanding that in the 2026 JavaScript supply chain, like others, it patches the leaks.

Run the three commands. Note your numbers. Compare them to eclecticlight.co every now and then. It takes thirty seconds, and it lets you know if you’re properly patched and up-to-date.

Read also: Lockdown Mode vs. Coruña, the government spy toolkit

Technical terms? Check the glossary.

kSuite vs Google Workspace, the honest comparison

Mac Souverain — Sun, 10 May 2026 14:27:21 GMT

Introduction

Every month, you fork out cash for Google Workspace. You’re a MacSouverain reader, so privacy’s a big deal for you. Eventually, the cognitive dissonance gets unbearable.

The question isn’t “Is Workspace bad?” It’s great, it’s the gold standard. The question is: what exactly are you paying for, and what are you trading for it? And is there an alternative that gives you your Mac, your jurisdiction, and your data back, without forcing you to downgrade?

kSuite, brought to you by Infomaniak from Geneva, makes that very promise. Let’s see if it delivers.

The Criteria That Matter

Comparing two collaborative suites without a grid is like doing a PR piece. Here are the six criteria I’ve chosen, and what I’ve deliberately left out.

Jurisdiction and Data Sovereignty. Where data is stored, under which law, who can access it legally. This criterion trumps everything else for MacSouverain because it’s structural and non-negotiable with features.

Real Encryption. Not “encrypted” in general. At-rest, in-transit, and especially end-to-end: who holds the keys. This is the only grid that withstands a warrant.

Price and Transparency. How much you pay per user, what you get, what changes when the editor does a “pricing update”.

Native macOS and iOS Integration. Apple Mail, Calendar, Contacts, Files. Can you work without installing a single app from the editor on your Mac. This is the “practical sovereignty” marker.

Professional Functional Coverage. Pro mail, shared drive, video conferencing, collaborative docs, admin console, SSO, MDM. A suite that forces you to keep another one nearby is a half-suite.

Exit Strategy. Export, standard formats, import from the competitor. You’re not married to your cloud provider, unless you choose to be.

What I DID NOT evaluate: very specific use cases (Workspace for Education, HIPAA compliance in the US, FedRAMP). If you’re an American hospital, this comparison isn’t for you. If you’re a European SME, a freelancer, or a family office, we continue.

kSuite, by Infomaniak

The philosophy in two sentences. A collaborative suite edited by a Swiss hosting provider of 316 employee-owned people, ISO 27001 and 14001 certified, operating its own datacenters in Geneva and Winterthur. Not a reseller slapping a UI on third-party bricks, a vertically integrated editor.

The strengths.

Swiss, no FADP, outside CLOUD Act. Infomaniak is under Swiss jurisdiction, governed by the new Federal Act on Data Protection (FADP, in effect since 01/09/2023). No CLOUD Act applies. Switzerland benefits from an adequacy decision for GDPR transfers. For an EU client or anyone attached to keeping their data from making a legal detour to Washington, that’s argument enough.

Built-in, free, transparent OpenPGP in kMail. Infomaniak enabled end-to-end encryption via OpenPGP in kMail webmail on June 17, 2025, for all plans, no add-on required. You enable, you exchange keys with your contact, your emails are encrypted end-to-end. Among major suites, only Proton and kSuite offer free OpenPGP in webmail. Google Workspace, Microsoft 365, and Zoho reserve their native encryption for Enterprise plans.

OnlyOffice under the hood of Docs, Grids, Points. The office suite engine in kSuite is OnlyOffice, AGPLv3, open source. High-fidelity compatibility with.docx,.xlsx,.pptx, better than Google Docs with native Office files. If your accountant sends you a.xlsx with macros and a wonky layout, OnlyOffice renders it correctly.

Open protocols everywhere. IMAP, SMTP, CalDAV, CardDAV, WebDAV. You configure Apple Mail, Calendar, Contacts, and Files.app without installing a single Infomaniak executable on your Mac. That’s rare, and it’s the purest integration criterion a cloud suite can tick.

kMeet with optional, free E2E. WebRTC video conferencing with optional end-to-end encryption activable when creating the meeting (shared key), documented by Infomaniak. Limited to Chromium browsers and desktop app, but it exists. Google Workspace’s equivalent (CSE) requires Enterprise Plus.

Transparent, stable pricing. kSuite Pro at 7.90 €/user/month for 3TB storage and full mail pro. No documented price increase since launch in 10/2022. The pricing promise holds.

The weaknesses.

MDM and Apple Business Manager: the gaping hole. No official ABM integration for kSuite. If you deploy a fleet of iPhones and Macs for business with federated authentication via Managed Apple ID, Workspace does it natively. kSuite requires a third-party MDM (Jamf, Mosyle, Kandji) with classic IMAP/CalDAV auth. It works, it’s less integrated.

Limited third-party marketplace. Google Workspace Marketplace has over 4,500 connected apps. kSuite has mostly Infomaniak suite and standard integrations. If your workflow relies on fifteen SaaS connected to Google Calendar, plan for a transition.

Mobile apps: solid, not reference. Infomaniak Mail and kDrive iOS are clean, but Gmail and Google Drive iOS remain the UX reference. It’s an experience gap, not a blocker.

Real-time co-editing: good, not excellent. OnlyOffice handles multi-user co-editing, but Google Docs is the absolute reference for latency and collaborative undo. If you spend all day simultaneously editing the same document with six people, you’ll feel the difference. Otherwise, not so much.

Euria vs Gemini. Infomaniak has its sovereign AI (Euria) for kMeet transcription and assistance. It’s decent, it’s not Gemini. If advanced AI-driven office suite is your top criterion, Google Workspace wins this point hands down.

Who it’s for. The freelancer, the SME, the family office, the liberal profession that wants a complete pro suite without CLOUD Act and without installing another proprietary app on their Mac. The MacSouverain profile, in short.

Prices (excerpts, real editor page on infomaniak.com/en/ksuite/ksuite-pro/prices).

my kSuite : free, 20GB, 1 @ksuite.infomaniak.com address, kMeet included. No personal domain.
my kSuite+ : CHF 5.75/month, 2TB, 1 domain + 5 aliases.
kSuite Standard : 1.90 €/user/month, 15GB per user, pro mail with domain.
kSuite Pro : 7.90 €/user/month, 3TB per user, pro mail + aliases, SSO SAML.
kSuite Enterprise : 14.90 €/user/month, 6TB per user, advanced admin.

Google Workspace, by Google LLC

Philosophy in two sentences. The collaborative suite that redefined the standard since 2006. Market reference for Gmail, Docs, Sheets, and Meet, integrated with almost every SaaS worldwide, under US jurisdiction and CLOUD Act.

Strengths.

Reference anti-spam email. Gmail filters better than anyone else, period. Fifteen years of machine learning feedback on billions of messages, that’s hard to beat. If you switch email providers, your spam folder will miss you for two months.

Co-editing Docs, Sheets, Slides. The inventor of the genre is also the master of it. Latency, suggestions, mentions, granular history: Google Workspace’s online office suite remains the reference, and all other suites measure up to it.

Giant third-party ecosystem. Google Workspace Marketplace, 4,500+ apps. Your CRM, your billing, your HR tool, your ATS: they all have a native Google connector. For kSuite, expect manual CalDAV/IMAP integrations when the third-party app allows it, or nothing when it doesn’t.

Official Apple Business Manager. Federated authentication with Managed Apple ID, DEP token, MDM deployment Workspace Endpoint Management covering macOS, iOS, ChromeOS, Android, Windows. For an SME managing a heterogeneous fleet, this is a real operational argument.

Gemini AI integrated into all plans. Since March 17, 2025, Google has bundled Gemini into the core tariff of Workspace. NotebookLM, Gemini in Docs, Gemini in Sheets, Meet transcription: it’s powerful, and it’s available without additional add-ons.

Vault, eDiscovery, DLP, BigQuery audit. If your profession has legal retention, legal hold, or serious data loss prevention obligations, Workspace Plus and Enterprise are mature on these topics for ten years. kSuite has audit logs, not the full regulatory stack.

Weaknesses.

CLOUD Act, the structural argument. Google LLC is a US company, subject to the 2018 CLOUD Act, which allows US authorities to demand data stored anywhere in the world from a provider under US jurisdiction. “European datacenter” doesn’t change anything: Microsoft France confirmed this under oath to the Senate. Workspace is not qualified SecNumCloud by ANSSI. The partnership with Thales S3NS to carry a qualification is underway, Workspace itself does not carry it.

Price increase in 03/2025, Gemini bundle imposed. Google increased the core tariff of all Workspace plans by integrating Gemini into the package: +16.7% on Business Starter and Standard (annual), +22.2% on Business Plus. You don’t have generative AI in your workflow? You’re still paying. This is the second global increase after 2023, Workspace pricing is continuously increasing.

End-to-end encryption reserved for Enterprise Plus. S/MIME hosted and CSE (Client-Side Encryption) are only available in Enterprise Plus and Education Plus, with an external KMS to configure (Thales, Fortanix, Stormshield, Flowcrypt). On Business Starter, Standard, and Plus, you have TLS in-transit and AES-256 at-rest with Google keys. That’s not E2E.

Native Apple apps: it works, but not great. Apple Mail with Google Account works, but Gmail labels become IMAP folders, the experience is degraded. CardDAV is officially deprecated by Google in favor of People API (still functional via native Google Account iOS, but long-term signal). In practice, the Workspace user ends up opening Gmail web and Drive iOS app: the “100% native Apple apps” argument falls apart.

Gmail lock-in. Gmail’s labels, filters, categorization are specific. Google Takeout exports everything (.mbox, EML), but reformatting on the new provider’s side isn’t trivial. You can leave, but it won’t be comfortable.

Customer data vs AI training. Google contractually commits not to use Workspace B2B data to train Gemini. That’s a contractual commitment, evolvable, separate from the commercial Gmail consumer engagement (which does share signals). Keep an eye on this over time.

Who it’s for. The company whose critical workflows depend on the Marketplace, the large group with serious eDiscovery needs, the US client where local compliance requires Google certifications, the team already set up with no operational argument to move.

Prices HT (annual, editor page workspace.google.com/pricing).

Business Starter: €6.80/user/month (annual), 30GB per user, Meet 100 participants, max 300 users.
Business Standard: €13.60/user/month, 2TB pooled, Meet 150 + recording.
Business Plus: €21.10/user/month, 5TB pooled, Vault eDiscovery, Meet 500.
Enterprise: quote-based, 5TB+, Meet 1,000, CSE, advanced DLP.

Launch promotion: 50% off for the first 3 months for the first 20 users, then standard pricing applies.

Face-to-face on the criteria that matter

Instead of a flat table that levels everything, let’s look at the six criteria one by one.

Jurisdiction and sovereignty

kSuite is Swiss, under the Swiss Federal Act on the Surveillance of Post and Telecommunications (FADP), hosted in Switzerland (datacenters in Geneva and Zurich region), outside the CLOUD Act, outside the GDPR (but with a valid EU adequacy decision). Workspace is US, under the CLOUD Act, global datacenters with the “data regions” Europe option in Enterprise plans. On this criterion, it’s not a comparison, it’s a difference in nature. If jurisdiction is decisive for you, the subject is already settled.

Real encryption

kSuite: Native and free OpenPGP E2E in kMail, optional in kMeet, AES-256 at-rest on kDrive with Infomaniak keys. No native E2EE drive. Workspace: TLS and AES-256 at-rest everywhere, hosted S/MIME and Customer-Supplied Encryption in Enterprise Plus only, BYOK with external KMS in Enterprise Plus. For email, kSuite wins hands down and for free. For the drive, both ask for a compromise: Infomaniak keeps the keys, or you pay for Workspace Enterprise Plus to have CSE.

Price and transparency

At equivalent tiers, kSuite is cheaper everywhere. Solo 2 To: my kSuite+ at 5.75 € against Business Starter at 6.80 € for 30 Go (a factor of 70 in storage). SME standard: kSuite Pro at 7.90 € against Business Standard at 13.60 € (kSuite 42% cheaper, 50% more storage). SME premium: kSuite Enterprise at 14.90 € against Business Plus at 21.10 € (kSuite 29% cheaper). And Workspace pricing goes up, kSuite’s hasn’t changed since 10/2022.

Native macOS and iOS integration

kSuite exposes IMAP, SMTP, CalDAV, CardDAV, WebDAV. Apple Mail, Calendar, Contacts, Files.app work natively without a single proprietary app installed. It’s the “100% Apple” scenario pure and simple. Workspace also works natively, but the real experience pushes the user towards Gmail web and Drive iOS. On the criterion of “installing nothing from the vendor”, kSuite wins without moving; on the criterion of “polished experience”, Workspace keeps the lead with its own apps.

Professional functional coverage

Both suites cover email, drive, calendar, contacts, video conferencing, collaborative docs, admin console, SSO. Workspace adds native MDM, official ABM, Marketplace with 4500 apps, advanced DLP, Vault eDiscovery. kSuite adds high-fidelity OnlyOffice, free OpenPGP, E2E kMeet. On pure coverage, Workspace has more depth; on functional sovereignty, kSuite has an edge.

Exit possibility

kSuite exports EML, MBOX, vCard, iCal, native OnlyOffice files. Workspace exports via Takeout (mbox, vCard, ics,.docx via conversion). Both let you leave. kSuite makes arrival easier: it has a documented Workspace import in the Manager console. The reverse (leaving Workspace for something else) works technically but isn’t guided.

Mack’s Recommendation

I’ll say it straight up because that’s my job: if you have a choice, kSuite is better than Workspace for your Privacy.

Not because Workspace is bad. Workspace is an excellent collaborative suite. But the MacSouverain user isn’t the average Workspace user. The reader of this site is a freelancer, a European SME, a family office, an independent who pays for a service and wants to know who can read their files, who can force them to be communicated, and what happens when an audit arrives. On these three questions, Workspace answers “Google, the CLOUD Act, we’ll handle it”, and kSuite answers “you, nobody, and an export EML file”, total Privacy.

If you’re a freelancer or solo and budget matters. my kSuite+ at CHF 5.75/month for 2TB is an obvious choice over Business Starter and its 30GB.

If you’re a 5-50 person SME in Europe. kSuite Pro at €7.90/user. You save 42% compared to Business Standard, keep your pro mail with domain, can configure Apple Mail and Calendar on the whole fleet without installing an app, and you’re out of the CLOUD Act. The only question to ask: does your fleet need federated MDM via ABM? If yes, seriously evaluate the cost of a Mosyle or Jamf as a complement.

If you’re already on Workspace with your whole workflow tied to it. A migration costs. You don’t have to do it this quarter. But there are two moments when reconsidering it makes sense: every time Workspace raises its prices (the next one is coming), and when a critical workflow breaks due to a Google change. Both moments will happen, statistically.

If you’re a family office in Switzerland, Germany, or elsewhere in the EU and US jurisdiction bothers you. You don’t pay an American cloud to store your pro correspondence and financial documents, it’s as simple as that. kSuite is the shortest answer.

For my personal use, I made a different choice, Proton Workspace, which makes the same sovereignty promise from a different angle (E2E everywhere by default, complete Proton ecosystem). If you’re hesitating between the two sovereign worlds, remember this grid: kSuite has the edge on pure native Apple integration (standard CalDAV, CardDAV, IMAP) and high-fidelity OnlyOffice; Proton has the edge on systematic E2E and the cohesive app suite. Neither brings you back to the CLOUD Act, that’s the essential part.

In summary

kSuite is cheaper than its equivalent, more sovereign by design (Switzerland, nFADP, employee-owned, ISO 27001), exposes open protocols that make native Apple apps fully usable, and includes free OpenPGP encryption in mail. Workspace is more polished on Gmail, Docs, and third-party ecosystems, more integrated with Apple Business Manager, and much more mature on Vault and DLP topics, at the cost of a US jurisdiction and continuous price increases.

In practice:

Freelance or solo, budget-conscious → my kSuite+ at CHF 5.75/month.
European SME 5-50 people → kSuite Pro at €7.90/user/month, with a third-party MDM if needed.
Critical Workspace workflow already in place → stay, prepare migration for the next pricing update.
Heavy US regulatory compliance → stay on Workspace.
EU family office, non-negotiable jurisdiction → kSuite, no hesitation.

Transparency: MacSouverain is affiliated with Infomaniak. Subscribing to kSuite via the links in this article supports the site, without changing the price you pay. If you want to help, it’s this way.

The Editors Themselves

Infomaniak, the employee-owned Swiss hoster from Geneva, has been editing kSuite since 10/2022. Product page, prices, and public ISO 27001 / 14001 / 5001 certifications.
Google Workspace, Mountain View, under US jurisdiction and CLOUD Act. Pricing page, security whitepaper, public ISO 27001.

Technical Documentation

kMail’s free OpenPGP announcement, picked up by Yahoo Finance on June 17, 2025.
Apple Business Manager × Workspace, Apple’s official guide. Native Managed Apple ID federation on Google’s side, not kSuite’s.

Independent Analyses

Wire, CLOUD Act vs EU sovereignty, Swiss messaging app Wire explains why a European datacenter isn’t enough if the company is US-based.
9to5Google, Workspace price hike 03/2025, tech press documenting the forced Gemini bundle and updated pricing grid.

Also see

Digital sovereignty, in practice: the general grid of which kSuite is a case study.
The cloud, it’s someone else’s computer: the mental framework behind this comparison.
DNS, the Achilles heel of your privacy: same logic of jurisdiction on another layer.

Little Snitch vs LuLu: Which outgoing firewall for your Mac?

Mac Souverain — Tue, 05 May 2026 11:57:32 GMT

MAJ juillet 2026. DNS4EU, cited below as the integrated encrypted DNS provider in Little Snitch, has closed at the end of May 2026 (insufficient resources). Little Snitch has replaced it with Quad9 in its presets. Whenever you read dns0.eu below, replace it with DNS4EU or Quad9.

Update, July 2, 2026. Little Snitch has moved to version 6.4.1 (June 2026): Touch ID unlock for settings, copy rules between profiles with drag and drop, hourly updates for block lists. Version 6.4.1 fixes rejection of old licenses. The comparison verdict remains unchanged, with the referenced versions below being up-to-date.

Introduction

While you’re reading this article, your Mac is talking. To forty-seven servers, without asking for your opinion. Apple iCloud, Adobe, Microsoft Telemetry, the weather app that wakes up a CDN in Singapore, the Solitaire game that posts your scores to an editor you don’t know.

No one, or almost no one, looks at the network output of their data.

That’s where the outgoing firewall on Mac comes into play. Not the integrated ALF (Application Firewall, which only filters incoming), not pf (powerful but blind to process). A real outgoing firewall process-aware that says “such a binary is trying to connect to such a domain, do you allow it?”. On macOS, two tools dominate: Little Snitch (paid, closed-source, Austrian) and LuLu (free, open-source, American, signed by Patrick Wardle).

Why an outgoing firewall process-aware

Outgoing firewall in two sentences. A software that intercepts outgoing connections from your apps before they go to the internet and asks “do I allow or block it?”. An incoming firewall does the opposite, filtering what comes in from the network. Little Snitch and LuLu play on the outgoing side only, that’s their job.

macOS natively provides two layers of security. ALF (Application Layer Firewall) filters incoming connections. XProtect and MRT scan binaries known to be malicious. That’s what you get out-of-the-box.

If you want more serious protection, you can pile on more on top: Santa (NorthPoleSec, OSS) to block unwhitelisted executables, Wazuh to send events to a SIEM, and precisely what this article is about, an outgoing firewall process-aware. All these layers, native or added on, do what they’re supposed to do, complementing each other.

An app can be signed, validated by Apple, run by a legitimate user, and send your address book to a third-party server. ALF sees nothing (it’s outgoing). Santa sees nothing (the binary is allowed to run). XProtect sees nothing (the binary isn’t in the malware database). That’s exactly what an outgoing firewall process-aware is for: filling that gap. Filtering not by IP address, but by process and destination, with an allow/drop verdict per connection.

On macOS, since Big Sur, these tools use the Apple NEFilterDataProvider framework (Network Extension). No more kernel extensions to load, no more risk of kernel panic linked to a third-party kext. Apple maintains the network path, the third-party tool just renders a verdict.

The protagonists

Little Snitch 6.4.1

Developed by Objective Development Software GmbH, in Vienna, Austria, since 2003. Twenty-two years old, stable team, no takeover, no pivot. Perpetual license, proprietary closed-source. One known security incident (code-signing flaw in 2018, fixed before public disclosure by Patrick Wardle). Since version 5 (2020), no more kernel extensions, only Network Extension Apple. Current version: 6.4.1, released on June 22, 2026, supports macOS Sonoma, Sequoia, and Tahoe. UI in English and German. No French.

LuLu 4.3.2

Developed by Patrick Wardle, founder of Objective-See (USA), since 2017. Wardle is a global security Mac reference: ex-NSA, creator of the Mac Malware Project, regular speaker at Black Hat, DEFCON, and Objective by the Sea. Open source, GPL-3.0, public sources on GitHub, compilable binary. 100% free model, funded by donations via Patreon (no freemium, no tiered pricing). Current version: 4.3.2, released on May 3, 2026. Supports macOS 10.15+, Tahoe included since version 4.0. UI mainly in English.

What they do, what they don’t do

Little Snitch (left) and LuLu (right) prompts. Official captures from obdev.at and objective-see.org. © Objective Development and © Objective-See, GPL-3.0.

Shared core product. Both are outgoing firewalls process-aware built on the same Apple NEFilterDataProvider framework, so the network path is dictated by macOS, not the editor. Reference versions here: Little Snitch 6.4.1 (released on June 22, 2026, first macOS Tahoe 26 supported since version 6.3) and LuLu 4.3.2 (released on May 3, 2026, GPL-3.0). Native Apple Silicon on both sides.

Rule granularity. Little Snitch lets you target by process, domain, port, protocol, network interface, time, and profile. LuLu lets you target by process, domain or IP, scope (specific process or global), and duration. The difference isn’t cosmetic: allowing Spotify between 8 am and 10 pm, on a specific port, or on a dedicated profile for the train, that’s Little Snitch only.

Network profiles. LS automatically switches to the Wi-Fi SSID or interface (trusted vs public network, adapted VPN profile). That’s the nomadic MacBook user’s argument that has no equivalent. LuLu has profiles since version 4.0, but the switch is manual. You choose before connecting, or you’ve forgotten.

Integrated encrypted DNS. LS offers DoH, DoT, DoQ to Quad9, Cloudflare, dns0.eu, Google (you get the idea, it’s not the MS choice), as an option directly in the app’s settings. You no longer need a separate system profile for encrypted DNS. LuLu has a basic toggle “Allow DNS Traffic” on UDP:53, encrypted DNS isn’t its problem, you handle it upstream (dnscrypt-proxy, AdGuard, etc.). And beware of the Network Extension conflict described below.

Wildcard DNS and the Chrome trap. LS handles CDN reroutings like Akamai or iCloud without breaking rules, because it does wildcard resolution on the domain side. LuLu doesn’t have wildcard hostname support (GitHub issue #379, requested for a long time, not implemented). The consequence is serious on the Chrome side: Chrome doesn’t use Apple’s Network.framework for DNS resolutions, so with LuLu, hostname blocking is ineffective on Chrome, fallback IP-only only (issue #410). If you live in Chrome, that’s a major limitation that’s little known.

Live Network Monitor and Research Assistant. LS has a real-time network map, a 5-minute traffic graph, a connection inspector per connection, and a Research Assistant that tells you what the community has already judged for that process (reduces whitelist fatigue). LuLu has Netiquette as a separate tool, not integrated into the prompt. No community reputation base.

Little details that add up. LS has a silent mode (auto-allow or auto-deny during a meeting or presentation), built-in blocklists (trackers, ads, malware, daily updates), configurable acoustic notifications per rule, bidirectional rules since LS 6, binary identification by code signature (resists replacement by a false binary at the same path), and usage statistics per rule.

LuLu doesn’t have silent mode (GitHub issue #540), no built-in blocklists, no sounds, no bidir (outgoing only by design), identifies the process by path (more fragile), and doesn’t store stats.

CLI and automation. LS offers a mature CLI littlesnitch with export-model, restore-model, diagnostics, switch-profile, write-rules. You can backup your rules model, version it, and restore it on another Mac (with user mapping if different and Keychain password if export is encrypted). Native JSON on the backup side, .lsrules JSON on the subscription rule set side, both Git-friendly.

LuLu doesn’t have an official CLI. The rule format is a fragile binary plist, user rule export exists since version 4.2.1 but remains less standardized. For a fleet of several Macs managed with infrastructure-as-code, the gap is direct.

Logs and SIEM. LS writes to a at.obdev.littlesnitch subsystem (macOS unified log), plus a local SQLite DB exploitable, plus a Wazuh decoder own decoder. LuLu writes to os_log without a documented subsystem, so tailing Wazuh on the manager side requires more regex and less structure. If you send your events to a SIEM (Wazuh, Splunk, Elastic), LS gives you proper material, LuLu gives you best effort.

Common macOS limitation. Only one active filtering provider at a time on the system. Activating LS, or LuLu, or a third-party encrypted DNS profile (NextDNS for example), not the three. That’s an Apple limitation, not a product flaw. LS works around it by integrating its encrypted DNS. LuLu doesn’t.

Release cycles. LS is regular, 6.3.1, 6.3.2, 6.3.3 in September-November 2025 then 6.4 and 6.4.1 in June 2026, stable team since 22 years. LuLu is more erratic, 4.2.0 in October 2023, 4.3.0 in March 2026, 4.3.2 in May 2026, project maintained on the available time of Wardle and the Objective-See foundation. Neither has French UI.

Score: Little Snitch covers about 22 complete features out of 24 checked. LuLu covers about 10 complete features, 5 partial features, 9 missing features.

The gap is clear. And it won’t close with the next LuLu release: some absences (CLI, encrypted DNS, integrated Network Monitor) are architectural choices, not oversights.

Sovereignty: LuLu wins

This is the most misunderstood point in the French debate, so let’s be direct.

LuLu is more sovereign than Little Snitch. Period.

Why? Three reasons that pile up.

1. LuLu is open source GPL-3.0. The entire code is on GitHub. You can read it, audit it, compile it yourself, fork it. No backdoor can be inserted without leaving a public trace. No editor kill-switch possible without a researcher noticing. No hidden telemetry holds up against a grep on the sources. That’s the verifiable trust model, not the delegated trust model.

2. Little Snitch is proprietary closed-source. The Viennese editor could be impeccable (and it is, for 22 years), you have no way to verify it other than delegating trust. Apple’s signature guarantees that the binary comes from Objective Development. It doesn’t guarantee anything about what that binary does. No formal independent audit has been published on Little Snitch (nor on LuLu, for that matter). On the rigor formality, the two tools are at the same level: zero published audit.

3. The “Wardle is American so US jurisdiction” argument doesn’t hold. An argument has been circulating since the release of the free Linux version of Little Snitch in 2025, especially on the marketing side of obdev: LuLu is American, so less sovereign than LS which is Viennese. That’s false, or at best misleading. For a simple reason: LuLu’s code is public, GPL-3.0, compilable locally. No US injunction can force Wardle to insert a backdoor without the community noticing in the next commit. The binary you compile from your local sources has no more jurisdictional link with Wardle. That’s precisely what open source auditable prevents: undetectable jurisdictional takeover. Meanwhile, Little Snitch remains closed-source on the EU side, so the sovereignty argument reverses literally when you look at audibility rather than the headquarters jurisdiction.

And Wardle isn’t just anyone. Ex-NSA, founder of Objective-See, creator of the Mac Malware Project, regular speaker at Black Hat and DEFCON, organizer of Objective by the Sea. His research has documented several bypasses of macOS firewalls (BlackHat 2018), which directly nourishes the defense of his own product. On the outgoing firewall Mac layer, that’s an authority.

Sovereignty verdict: LuLu, no debate. If sovereignty is your absolute criterion, the arbitration is trivial. If someone sells you Little Snitch as “more sovereign because EU editor”, they’re confusing jurisdictional sovereignty (true for other layers: Proton, dns0.eu) and audibility (the real question on code that inspects your traffic).

LuLu rules window, official capture from objective-see.org. © Objective-See, GPL-3.0.

Functionality: Little Snitch wins

On the other axis, the gap is just as clear, but in the other direction.

Five features tip the choice as soon as you go beyond “I just want an app to stop phoning home”.

1. Automatic network profile switch on SSID. You’re at home on your Wi-Fi: permissive rules. You push your MacBook onto a café’s Wi-Fi: strict rules (blocklist trackers activated, forced encrypted DNS, restricted business apps). You’re at the office: pro profile that allows internal tools. Little Snitch automatically switches to the SSID. LuLu has profiles, but the switch remains manual. For a nomadic MacBook user, that’s a point to consider.

2. Integrated encrypted DNS. DoH, DoT, DoQ to Quad9, Cloudflare, dns0.eu, Google (you get the idea, it’s not the MS choice), as an option directly in the app’s settings. LuLu has a basic toggle “Allow DNS Traffic” on UDP:53, encrypted DNS isn’t its problem, you handle it upstream (dnscrypt-proxy, AdGuard, etc.). And beware of the Network Extension conflict described below.

3. Mature wildcard hostname. iCloud, Akamai, Adobe, and most modern CDNs constantly rotate their IPs. An “allow *.icloud.com” rule holds up. An “allow 17.X.X.X” rule breaks at the first rotation. Little Snitch handles wildcards properly. LuLu doesn’t (GitHub issue #379, not implemented). And on Chrome, which doesn’t use Apple’s native network framework, LuLu falls back to IP-only filtering, which means your hostname blocking no longer works at all on Chrome (issue #410). That’s a major limitation that’s little known.

Little Snitch Network Monitor, official capture from obdev.at. © Objective Development.

4. Real-time Network Monitor. During the whitelist phase, or during an audit, you want to see the live traffic: who’s talking to whom, what volume, what geographic destination. Little Snitch has a live map and a 5-minute graph integrated into the app. LuLu offers Netiquette, an Objective-See tool that you have to launch separately. It’s OSS and it does the job, but it’s less fluid.

5. Scriptable CLI for the fleet. That’s the point that tips the scale as soon as you have more than two Macs to manage. Little Snitch exposes a littlesnitch binary that knows how to do export-model (backup JSON of the rules model), restore-model (restore from JSON file, with user ID mapping and Keychain password if export is encrypted), diagnostics, switch-profile, write-rules. The real-world workflow on a fleet looks like this: ssh mac-source littlesnitch export-model > rules.json on the reference Mac, you commit rules.json to a Git repo, and on each target Mac you do scp rules.json mac-target: then littlesnitch restore-model -m oldUID>newUID rules.json. Not a one-liner magic pipe stdin, but versioned, diff proper, code review possible. LuLu doesn’t have an official CLI. To push rules, you copy a fragile binary plist, which changes format between versions, without any guarantee of reproducibility.

Functionality verdict: Little Snitch, no debate. If you want the maximum granularity, nomadic profiles, scriptable fleet, and proper SIEM integration, the arbitration is quick.

Common limitations (that no one else tells you about)

Before you decide, four limitations that apply to both tools. Honest radicalism, we don’t pretend.

1. Apple apps that bypass Network Extensions. Since Big Sur, Apple has a whitelist of system apps exempted from any third-party NEFilterDataProvider filtering. Apple Mail, App Store, some iCloud services bypass Little Snitch like they bypass LuLu. Neither sees 100% of Apple’s native traffic. That’s not a product flaw, it’s Apple’s decision, and it’s documented (Michael Tsai 2020).

2. Network Extension conflict. macOS only allows one active filtering provider at a time. You activate Little Snitch, or LuLu, or a third-party encrypted DNS profile (NextDNS, dns0.eu), not the three. That’s a platform limitation, not a product flaw.

3. No formal independent audit. Neither Little Snitch nor LuLu has had a published third-party audit type Cure53, Trail of Bits, or ANSSI/CSPN. That’s a limitation to know. On the LuLu side, open source GPL-3.0 compensates (continuous community audit). On the Little Snitch side, the 22-year track record without a major incident partially compensates (one known code-signing vuln in 2018, fixed before public disclosure). But on the formal rigor, the two tools are at the same level: zero published audit.

4. The whitelist phase is a hidden cost. During the first days of use, you’ll be prompted every two minutes. Your OS, your apps, your antivirus, your backup, your mail client, each wants to join something. Budget one to two weeks of serious friction before your rules model is stable. That’s true with both tools. If you’re not patient, disable rather than authorize everything without looking (auto-allow by default breaks the very purpose of the tool).

How much it really costs

LuLu is zero euros. No freemium, no tiered pricing, donations via Patreon optional. If you want to support Wardle and the Objective-See foundation, do it. It’s not mandatory to use the product.

Little Snitch is more subtle. The public obdev.at grid, last verified on May 5, 2026, offers five pricing options. The Single License at €59 for one Mac. The Family License at €115, on which obdev doesn’t specify how many Macs are covered on the order page, so clarify with support before purchasing. The Multi License explicitly, 5 Macs at €239 (around €48 per Mac) or 10 Macs at €419 (around €42 per Mac). And the Snitch Bundle (Little Snitch + Micro Snitch, the microphone/camera control of the same editor) at €63.49 for one Mac.

Perpetual license, no subscription. Major upgrade (5 → 6 for example) = reduced price upgrade. Over time, you pay once, use until the next major version.

For a fleet of 5 Macs in Multi License, the real cost is around €48 per Mac, perpetual license. For 10 Macs, around €42 per Mac. That’s a calculation no one makes, but it changes the comparison with the “€59 per Mac” cited everywhere.

Verdict on two axes

No unique winner. Two axes, two winners, a choice that depends on your priority criterion.

If sovereignty is your absolute criterion: LuLu.
Open source GPL-3.0, verifiable code, binary compilable locally, author of reference security Mac. No undetectable jurisdictional takeover. Free. You accept in exchange a lower granularity, no automatic profiles, no integrated encrypted DNS, no CLI fleet. For a single Mac, personal use, basic process blocking, that’s more than sufficient.

If rich functionality is your absolute criterion: Little Snitch.
Automatic SSID profile switch, integrated encrypted DNS, mature wildcard hostname, real-time Network Monitor, scriptable CLI, proper SIEM integration. You accept in exchange proprietary closed-source (with a Viennese editor stable for 22 years, but not auditable), a cost license (around €42 to €48 per Mac depending on the pack), no French UI. For a nomadic MacBook user, fleet management, or serious SIEM integration, that’s the tool.

Neither is “better in the absolute”. They answer two different questions.

And if you’re still undecided: start with LuLu. Free, OSS, two clicks to install. If after two months you feel the granularity is lacking, the wildcard is frustrating, or the fleet scripting is a chore, switch to Little Snitch with knowledge of cause. The opposite (starting with LS paid and descending to LuLu) costs €59 more for nothing.

No affiliation with Objective Development, no commercial link with Objective-See. This article does not earn any money on Little Snitch purchases.

Sources

The editors themselves

Objective Development (obdev.at), the Austrian company developing Little Snitch since 2003: product page, release notes, press releases
Objective-See (objective-see.org), Wardle’s foundation publishing LuLu freely

The code and the technical documentation

LuLu’s source code on GitHub, freely readable, with public discussions between the author and users (bugs, limitations: #280, #379, #410)
Apple’s documentation on NEFilterDataProvider, the interface both tools use since Apple closed the old method in 2019

Independent analyses

MacGeneration, French reference site on the Apple ecosystem, for the review of Little Snitch 6
Howard Oakley (The Eclectic Light Company), British engineer who dissects macOS internals, to understand how these firewalls integrate into the system
Patrick Wardle himself, for the announcement of LuLu v4 on his Patreon (2025) where he documents the complete refactoring of the firewall

Proton Meet: Encrypted Vision, End-to-End Encryption for Maximum Privacy

Mac Souverain — Thu, 30 Apr 2026 10:24:38 GMT

Introduction

You’re scheduling a Zoom meeting with your accountant to discuss numbers, or a Teams call with a client to finalize a contract. You trust the lock icon in the browser.

Problem: that lock protects data transport, not content. Zoom, Teams, and Google Meet decrypt your call on their servers by default to process video, audio quality, and automatic captions. That’s called “transit encryption,” not “end-to-end.” All three offer an optional E2EE mode, but it disables most smart features and remains invisible to 99% of users.

Proton launched Proton Meet on March 31, 2026. Its promise in one sentence: not even Proton can access your calls, screen sharing, or chat. The encryption keys never leave the participants’ devices. Let’s see what that means concretely, who it’s really for, and where the real limits are.

What Zoom and Teams do with your meetings

Let’s set the context first. When you use Zoom, Google Meet, or Microsoft Teams, your audio and video data is encrypted as it travels between your device and their servers. Nothing shocking so far. But on their servers, that data is decrypted for processing.

Why? Because all the “smart” features you use daily require it. Automatic captions, noise suppression, background blur, adaptive video quality optimization: all of that needs access to the raw content of your call. This model is called “transit encryption,” and it’s perfectly legal and well-documented in the terms of service no one reads.

What that concretely means:

Zoom can be legally compelled (CLOUD Act) to hand over call content (unless you’ve enabled its optional E2EE mode, which is never the default)
Google can feed the personal profile associated with your account with call metadata (who, when, duration) if you’re using a regular Google account. In Workspace, Google contractually doesn’t use it for ads. But they keep it anyway (audit, “service improvement,” CLOUD Act). Not zero-knowledge.
Microsoft Teams stores meeting metadata (who, when, how long, with whom) in its systems

Zoom probably doesn’t systematically listen to your business calls. But legally and technically, it could. That’s the problem, not the stated intention.

Read: What digital sovereignty means in practice

How Proton Meet works differently

End-to-end encryption, E2EE, changes the game. Your data is never accessible in plaintext on Proton’s servers because the decryption keys never leave your and your interlocutors’ devices.

Proton Meet uses the MLS, Messaging Layer Security protocol, developed by the IETF, the same organization that standardizes fundamental internet protocols. MLS is specifically designed for groups: it efficiently manages participant entries and exits during a call without having to re-encrypt the entire session every time, a technical problem that naive E2EE implementations struggled with.

What that practically covers:

Audio and video, obviously
Screen sharing, entirely
Real-time chat during the call

What “even Proton can’t see” means technically: Proton’s servers see encrypted packets they can’t decrypt. They know a meeting is happening (they manage the signaling), but not what’s being said, shown, or written.

Proton Meet’s code is open source. Proton regularly has its products audited by independent firms (Mail, VPN, Drive, Pass); an audit dedicated to Meet is expected after launch. Open source allows any security researcher to verify that the claims match the actual implementation.

The plans and what they cover

Free version:

Up to 50 participants
Maximum duration: 1 hour per call
Proton account required to create the meeting; no account required for invited participants (a browser link suffices)
Instant meeting link creation, share with one click
Screen sharing and chat included

For an independent who wants to have a client meeting without friction, this is immediately usable. You create the link, send it, your client clicks, and the call starts in their browser. No installation or Proton account required for participants.

Meet Professional (starting at $7.99 USD/user/month, included in Workspace plans):

Up to 250 participants
Duration: up to 24 hours per call
Advanced moderation features
Proton Calendar integration

Proton Workspace (Standard and Premium), for teams:

Proton Workspace positions Meet as a component of a complete suite that includes Mail, Calendar, Drive, Docs, Sheets, VPN, Pass (team password manager), and Lumo, an AI privacy-first assistant available on the Premium plan.

Workspace Standard (€12.99/user/month with annual billing): 1 TB per user, Meet up to 100 participants, 15 email domains, Mail, Calendar, Drive, Docs, Sheets, VPN, Pass.

Workspace Premium (€19.99/user/month with annual billing): 3 TB per user, Meet up to 250 participants, 20 email domains, Lumo (AI privacy-first) included, email composition assistant, configurable retention policies.

Workspace targets teams looking to replace Google Workspace or Microsoft 365 with a fully encrypted alternative. It’s the direct PME target: you keep a complete collaborative organization (email, documents, meetings, passwords) but switch to a Swiss jurisdiction with an economic model based on subscriptions, not ads or data resale.

Proton AG is ISO 27001 certified and audited SOC 2 Type II. Workspace is compatible with GDPR, HIPAA, and CCPA.

What that concretely means for an independent or a SME

For situations where confidentiality matters:

Meeting with a lawyer to discuss a dispute. Meeting with your accountant about a restructuring. Exchange with a client sharing sensitive data. Code review with your team on a confidential project (and you should consider all your projects confidential).

In these situations, the difference between “transit encrypted” and “end-to-end encrypted” isn’t theoretical. It’s the difference between a document in an envelope and a document in a safe that the courier can’t open.

Zero friction for your counterparts:

Your client doesn’t need to create an account, download an app, or ask “what’s Proton?” You send them a link, they click, they’re in the meeting from their browser. That’s the level of friction of Zoom or Google Meet, with the level of confidentiality of an architecture fully encrypted end-to-end. That’s the strongest argument to convince your team or a reluctant client.

For remote teams:

If your team is already in the Proton ecosystem (Mail, Drive), Workspace Standard or Premium gives you access to Meet with participant and duration limits that fit most professional uses. The promise of not having to leave the sovereign ecosystem for a video call is real.

What Proton Meet doesn’t do (yet):

No cloud recording on Proton’s side: architecturally consistent with E2EE, the server can’t record what it can’t decrypt. Local recording on the host’s side remains possible if needed (compliance, documentation). No automatic transcription, real-time captions, or AI summaries either: these features require server-side processing of plaintext content, incompatible with strict E2EE. That’s the trade-off: privacy or server-side AI, not both.

Read: Apple Mail vs Gmail vs Proton Mail: the honest comparison

The real limits to know

The free version is limited. One hour per call might not be enough for a wide client interview, workshop, or training. 50 participants is sufficient for most team meetings, but it’s just enough for a webinar.

Migrating your ecosystem has a cost. If your team is used to Teams with its Office 365 integrations, switching to Workspace won’t be seamless. Proton’s docs (Docs, Sheets) are functional but haven’t yet reached the maturity of Google Workspace in advanced collaboration features. It’s a choice, not an improvement across the board.

Third-party integrations are limited. Proton Meet natively integrates with Proton Calendar for inserting meeting links. Beyond that, integrations with tools like Slack, Notion, or CRMs are absent or limited, where Zoom and Teams have years of ecosystem behind them.

The price compared to the competition. The fair comparison isn’t Proton Meet vs another video conferencing service. You need to look at the suites as a whole.
Proton Workspace Standard (€12.99/user/month with annual billing) vs Google Workspace Business Starter (~6.80 €/user/month) or Microsoft 365 Business Basic (~6 €/user/month).

Proton is roughly twice as expensive. Google and Microsoft offer E2EE as an option, but it disables features like captions and transcription. Proton Meet doesn’t offer those features either, but that’s by design, assuming strict E2EE from the start. The price delta is the cost of a complete privacy service that lives off your subscription, not your data.

Read: Proton Bridge + Apple Mail on Mac: encryption without sacrificing comfort

For those in a hurry

Proton Meet is an end-to-end encrypted video conferencing service using the MLS protocol, open source, independently audited, based in Switzerland. Launched on March 31, 2026.

Free plan: up to 50 participants, 1 hour. Your guests join from their browser, no account or installation needed.

Meet Professional: up to 250 participants, up to 24 hours, starting at $7.99 USD/user/month (included in Workspace Standard and Premium plans).

Proton Workspace: a complete suite for teams with Mail, Calendar, Drive, Docs, Sheets, Meet, VPN, Pass, available in Standard and Premium (with Lumo AI included for Premium).

It’s not a universal replacement for Zoom or Teams. It’s the right choice if the architectural confidentiality of your meetings matters to you, or if you’re already in the Proton ecosystem.

If you want a fully encrypted suite for your team without relying on an American infrastructure subject to the CLOUD Act and the 5 Eyes jurisdiction, and you don’t want your data feeding a ad system, Proton Workspace is a very serious candidate to evaluate.

For an independent with client calls under one hour, the free plan with a maximum of 50 participants is more than sufficient. For a team looking to migrate away from Google Workspace or Microsoft 365: Proton Workspace deserves a serious evaluation.

Need tech terms explained? Check the glossary.

Six months and nineteen global texts, the terrifying convergence

Mac Souverain — Thu, 30 Apr 2026 08:43:55 GMT

JULY 2026 UPDATE. No calendar on the CSAR side: the trilogue on May 4th took place, and on July 9th the Parliament allowed the renewal of Chat Control 1.0 (voluntary, E2E excluded) without the 361 votes needed to block it, majority against. Mandatory scanning (2.0) described in this map is not settled: it goes back to trilogue in September. Details in the radar.

Your Privacy? It’s not really yours anymore.

No one took it from you all at once, no. That’s for rushed regimes. They’re just nibbling at it, slowly, so you don’t notice.

A bill in Washington making your Mac an identity checkpoint. An EU regulation replacing your encrypted messages with a snitch. A jury in New Mexico slapping Meta with a $375 million fine for daring to deploy strong encryption.

Six months. Nineteen texts. Four continents. One direction.

Here’s the map.

Three mechanics, one trajectory

The nineteen texts I’m presenting don’t look alike on the surface. An American law, a European regulation, a court decision, a private product. But piled up, three mechanics emerge, and they work together.

M1, universal identification. No more anonymity on the internet, not even for adults. Every connection, every sign-up, every message demands an identity proof.

M2, breaking end-to-end encryption. Encryption stays on paper. But contents are scanned before it applies, or deploying it becomes legally risky.

M3, centralization with two or three actors. Apple, Google, Microsoft, or a Sam Altman eager to monopolize humanity verification. You no longer log in to a site, you log in through an identity broker.

Most of these texts passed under the radar because they arrived one by one. When you see them together, the picture changes.

M1, universal identification without adult exception

On April 13, 2026, Josh Gottheimer (D-NJ) and Elise Stefanik (R-NY) introduced HR 8250 Parents Decide Act in the US House of Representatives. The bill requires Apple, Google, and Microsoft to demand a birthdate when creating any account, and then expose that information to app editors via a dedicated interface. No adult exception. You set up a new Mac in 2027, the system identifies you, and every app can read it.

Andy Yen, CEO of Proton, summed up the issue in one sentence: « We cannot accept a world where every adult has to present an ID just to go online. » Eight days later, the Illinois HB 5511 was passed by the House, 82 to 27. The same logic, moving age verification from apps to the OS, harder to circumvent because the OS is linked to the verified account and the payment method.

This logic isn’t just American. The UK Online Safety Act came into effect on July 25, 2025. In the first quarter of 2026, the Ofcom opened over ninety investigations and issued six fines, including a £1.35 million fine against 8579 LLC. Australia activated its Online Safety Amendment on December 10, 2025, extended to ten platforms. Brazil enacted law 15,211/2025 in September 2025. And on April 14, 2026, the European Commission unveiled its harmonized age verification app for the twenty-seven member states.

By the way, it was hacked in two minutes by a British consultant, Paul Moore. For the details, you can read the radar at the link below. Either laughable or crying, depending on your perspective.

Read: EU Age Verification, Hacked in 2 Minutes, the Poorly Coded Surveillance

On March 2, 2026, 371 cybersecurity researchers from 29 countries signed an open letter. Ronald Rivest, Turing Award and co-inventor of RSA. Bart Preneel, president of the IACR. Not exactly Sunday activists.

The letter argues that the method isn’t secure and risks exposing users to malware or scams on illegal sites that don’t implement age verification, or revealing more personal information to service providers. Their conclusion on the deployments in progress: « dangerous and socially unacceptable ».

To make age verification work properly, they write, « state-issued IDs with strong cryptographic protection » are needed for every interaction with the service.

M2, breaking encryption in law or in case law

On the EU side, the dossier is known, I’ve detailed it before.

Read: Chat Control 2.0: The EU Wants to Read Your Messages Before You Send Them

Read: NIS2 Forces Companies to Encrypt. CSAR Prevents Them From Doing It Properly.

The novelty here is the admission. Vera Jourova, Vice-President of the Commission, publicly acknowledged at the EDPS summit that CSAR would break encryption. Three years of « CSAR doesn’t break encryption » discourse from Ylva Johansson, refuted by her own colleague. The next trilogue is set for May 4, 2026, with adoption targeted for July. The clock is ticking.

But the most brutal attack on end-to-end encryption comes from the US, and it’s not a law. It’s case law, and it’s much worse.

On March 24, 2026, a jury in New Mexico condemned Meta to a $375 million fine for civil penalties. The attorney general used Meta’s decision to deploy end-to-end encryption in Messenger as proof of irresponsibility towards minors.

And the sequence that follows is even more telling than the verdict: during the trial, before even the sentence, Meta announced the withdrawal of end-to-end encryption from direct Instagram messages. Effective on May 8, 2026. The mere existence of the trial was enough to decide them.

And the real problem with case law is that one judge was enough to make all the others adopt his ruling in other judgments. With heavy fines to follow, which will discourage startups from aiming to encrypt their services in the very near future. Because $375M for Meta is pocket change. For a startup, it’s death.

Even more effective than a law or a regulation.

While it may be tempting, we can’t blame the judge alone. Meta’s voluntary (?) irresponsible behavior shaped the decision. I’ll explain:

An internal note signed by Monika Bickert (director of content policy at the time) ended up in the trial documents. Irony at its peak: « We’re about to do something bad as a company. It’s so irresponsible. » Bickert wasn’t criticizing encryption itself, she was warning her superiors about the timing.

Enabling end-to-end encryption by default on Messenger without first finding a way to detect abuses involving minors was like voluntarily blinding Meta’s systems. The prosecutor in New Mexico used this note to prove the hardest thing to prove in a civil case: that Meta knew its decision would let predators through, and made the decision anyway.

Here, it’s really important not to get the roles wrong. Meta isn’t the victim of the trial. For Zuckerberg, end-to-end encryption was never a value, it was a marketing argument to stay competitive against WhatsApp and Signal.

That’s exactly what separates Meta from Signal or Proton. Signal can’t remove end-to-end encryption, it would dissolve the product. Proton can’t either, its entire proposition rests on it. Meta can, because for them, end-to-end encryption was an optional feature, not a foundation.

And that’s precisely what creates the precedent that judges can use against Signal or Proton later. « See, even Meta backed down, you can too. » Meta isn’t just the victim of the end-to-end encryption retreat. It’s actively participating in it.

And that’s also Bruce Schneier’s conclusion. Deploying strong encryption on your product can now be attacked legally as an act of bad faith. Not illegal in itself. Just… harmful in civil court, before an American judge.

The US picture is completed with FISA Section 702. The law was set to expire on April 20, 2026. Congress voted a ten-day emergency extension and blocked the « warrant requirement » amendment in advance. The NSA is vacuuming up communications of targeted foreigners outside the US, Americans who write to them then enter the base, the FBI queries it without a warrant. Seven thousand US-person queries in 2025, under-declared by the DOJ itself.

At the other end of the world, Hong Kong. On March 23, 2026, the enforcement rules of the National Security Law were modified, the police can now demand your passwords and your encryption keys. Refusing is a criminal offense. Schneier wrote a blog note about it. Hong Kong is forcing it. Democracies, they’re circumventing it through contract (CSAR), through case law (Meta NM), or through age barriers at the OS level (US). Same result, different packaging.

Convergence without coordination, but convergence nonetheless.

M3, private and public brokers, identity as infrastructure

Once HR 8250 is passed, or Illinois HB 5511, Apple and Google become age brokers. Not by choice, by legal constraint. Technically, it’s just a regional option, the kind of switch Apple already flips for the GDPR. The real risk is that other governments will see the system running in the US and copy it. Reverse GDPR effect, by mimicry.

While states debate, Sam Altman is pushing his private alternative. On April 17, 2026, World ID announced its integration with Tinder, Zoom, DocuSign, Okta, Shopify, and VanEck. Eighteen million users already verified by iris scan (The Orb), in 160 countries. The pitch: « the first decentralized identity layer for humanity », against bots and deepfakes, which the same industry AI produces in bulk.

It’s elegant. You create the problem (AI deepfakes), you sell the solution (iris scan), and in the process, you build a private global biometric database, connected to Tinder, Zoom, DocuSign, and Shopify. The scanned becomes a free beta tester of humanity, paying with their iris. The AI industry gets even more free, high-quality data, but especially qualified.

You can’t really do better than that, can you?

On the state side, the UK is advancing its GOV.UK Wallet and its digital driving license, full deployment by the end of 2026. Not mandatory yet, physical cards still valid until 2030. But the infrastructure is there, ready to become mandatory whenever a future government decides.

Three actors emerge as dominant identity brokers, Apple plus Google on the OS side, World ID on the private global side, GOV.UK Wallet and its twins on the state side. No one coordinated. The convergence is political, economic, structural.

Why this convergence

It’s not a conspiracy. It’s more boring than that, it’s systemic mechanics.

First, transatlantic imitation. The UK Online Safety Act passed in 2023 served as a model. Australia replicated it in 2025. The European Commission cited it explicitly as « good practice » for its age verification app. HR 8250 and Illinois HB 5511 picked up the same architecture six months later. No secret coordination, just « look, it works there, let’s copy it ».

Next, the zero marginal cost for Apple, Google, and Microsoft. Once the age verification infrastructure is built on the OS for one state, exporting it to other countries costs nothing more.

Finally, regulatory momentum creates the private market. Platforms are looking for identity verification providers? Worldcoin raises its hand. States want their sovereign wallet? Integrators (Thales, IDEMIA, Entrust) position themselves on eIDAS 2.0 calls for tenders. Regulation creates need, the market sells the solution.

The result is exactly what the letter from the 371 researchers warned about, a system where every interaction with an online service requires an identity proof issued by a state or a private broker.

The counter-movements

Ending on a totally defeatist note would be unfair.

On April 1, 2026, Governor Brad Little signed Idaho SB 1299, which prohibits government entities in the state from requiring a digital ID. The first US state to push back frontally, text legally solid and replicable.

Two days later, Governor Tony Evers of Wisconsin exercised a veto on AB 105, on an age verification bill for adult sites. The first governor veto in US history on an age verification bill, three well-argued objections, intrusion on adults’ privacy, no restrictions on sharing, vulnerabilities exposing users to theft and blackmail.

On April 23, 2026, Thomas Massie (R-KY) and Lauren Boebert (R-CO) introduced HR 8470 Surveillance Accountability Act. Warrant and probable cause required before any surveillance of Americans, close the « data brokers » loophole. Bipartisan in spirit, a sign that the surveillance debate is crossing both parties.

And on April 8, the French DINUM announced the migration of 2.5 million administration posts to Linux. David Amiel, Minister of the Budget, requests ministerial plans before the autumn 2026. Seven axes for reducing dependence, sovereign video conferencing for 200,000 agents by the end of 2026, 2.5 million by 2027.

Let’s be honest for two seconds. France isn’t migrating to protect the privacy of its civil servants, it doesn’t care. It’s migrating because depending on Microsoft costs between 500 and 800 million euros in licenses per year, and because a Trump 2.0 has finished reminding Brussels and Paris that an American provider can be shut down by a White House decree. Budget sovereignty and strategic sovereignty. Privacy nowhere.

But that’s precisely why the example is interesting. A state exits a hegemonic stack for reasons of money and geopolitics, not ideology.

**And the result, by effect, is that its 2.5 million civil servants stop being continuously telemetred by Redmond.

What a state does for its reasons, a citizen can do for theirs. And protecting your online privacy today is a political choice, not a crime, at least not yet.

Sorting it out, technically and politically

I use Proton Mail and a self-hosted Stalwart mail server for emails, Matrix for instant messaging, a Tailscale wireguard mesh network with Mullvad exit node for security, an unbound self-host DNS resolver, and various other open source tools for my digital sovereignty.

It’s not absolute, of course, but it’s already a huge independence, real privacy, a significant limitation for commercial or state third parties to continuously track you.

Except for Proton, and Infomaniak’s VPS hosting, all these tools are free, open source, audited for the most part, and supported by dynamic communities. Proof that privacy isn’t dead, and it interests many people.

You’re not obliged to go that far, of course, but for your professional activity in particular, I strongly recommend going that far. But every step you take for your privacy counts. It’s your inalienable right to dispose of your digital data as you see fit, and to define who you share it with. It’s as fundamental as the freedom to come and go.

If CSAR passes, if HR 8250 progresses, and you feel concerned, the right reflex is to choose architectures whose technical design makes it impossible to scan your data, and tracking extremely difficult.

Signal and Proton can’t implement client-side scanning without breaking their model. It’s not a policy, it’s an impossibility. Choosing them, or others built on the same model, protects you.

Read: What Digital Sovereignty Means in Practice

Politically, if you’re interested, write to your representatives. The CSAR trilogue on May 4, 2026, is a tipping point. Public pressure worked on Chat Control 1.0, it can work on CSAR 2.0.

EDRi, EFF, noyb maintain tools for direct contact with citizens. Use them and participate in the action, if it speaks to you.

And follow the MacSouverain Radars. Every text, every verdict, every tightening is followed in real time. Vigilance for privacy is daily attention, not episodic.

For the impatient

Six months, nineteen texts, four continents. Three mechanics that fit together, universal identification, breaking encryption, centralizing identity data with two or three brokers. This isn’t a conspiracy, it’s converging trajectories that will result in less privacy, or even no privacy at all, if they’re combined in each country.

Everyone comes out winning, that’s how it’s sold, except for the final user, if you read carefully. Everyone else.

Idaho SB 1299, Wisconsin veto Evers, Surveillance Accountability Act, 371 researchers, real points of support, demonstrate that another path is possible.

Your technical choices today, Signal, Proton, well-configured and up-to-date MacOS, Linux why not, are also political choices. And supporting EDRi and EFF, refusing convenience features that pave the way, is also the right way to combine the two.

What’s happening isn’t written yet, but it’s already inscribed in a trajectory.

It’s up to you to choose what you make of it.

Sources

Official texts and legislation

HR 8250 Parents Decide Act, Congress.gov : https://www.congress.gov/bill/119th-congress/house-bill/8250/text
Illinois HB 5511 Digital Age Assurance, ILGA : https://ilga.gov/Legislation/BillStatus/FullText?GAID=18&DocNum=5511&DocTypeID=HB&LegId=167486&SessionID=114
HR 8470 Surveillance Accountability Act, GovTrack : https://www.govtrack.us/congress/bills/119/hr8470/text
Idaho SB 1299, Idaho Legislature : https://legislature.idaho.gov/sessioninfo/2026/legislation/S1299/
UK Online Safety Act enforcement, Ofcom : https://www.ofcom.org.uk/online-safety/protecting-children/age-checks-to-protect-children-online
Australia Online Safety Amendment, eSafety : https://www.esafety.gov.au/about-us/industry-regulation/social-media-age-restrictions
New Mexico Department of Justice, Meta verdict : https://nmdoj.gov/press-release/new-mexico-department-of-justice-wins-landmark-verdict-against-meta/
UK GOV.UK digital driving licence : https://www.gov.uk/government/news/digital-driving-licence-coming-this-year

Analyses and coalitions

EDRi, ECtHR on encryption as a fundamental right : https://edri.org/our-work/european-court-of-human-rights-confirms-weakening-of-encryption-can-violate-the-human-right-to-privacy/
Bruce Schneier on Meta NM ruling and encryption : https://www.schneier.com/blog/archives/2026/04/new-mexicos-meta-ruling-and-encryption.html
Bruce Schneier on Hong Kong NSL : https://www.schneier.com/blog/archives/2026/04/hong-kong-police-can-force-you-to-reveal-your-encryption-keys.html
Open letter from 371 cybersecurity researchers, Euronews : https://www.euronews.com/next/2026/03/02/dangerous-and-socially-unacceptable-experts-warn-against-rushed-rollout-of-online-age-chec
Andy Yen, Proton CEO, on HR 8250, The Register : https://www.theregister.com/2026/04/23/proton_ceo_age_checks_id_checkpoint/
EU age verification app hacked, Cybernews : https://cybernews.com/security/eu-age-verification-app-hack/
World ID partnerships, TechCrunch : https://techcrunch.com/2026/04/17/sam-altmans-project-world-looks-to-scale-its-human-verification-empire-first-stop-tinder/
France DINUM, IT Social : https://itsocial.fr/logiciel-agilite/logiciel-agilite-actualites/la-dinum-lache-windows-pour-linux-et-impose-un-plan-de-souverainete-numerique-a-chaque-ministere-avant-lautomne/
Wisconsin veto Evers, 404 Media : https://www.404media.co/wisconsin-age-verification-bill-vetoed/

The DNS, your digital Achilles heel.

Mac Souverain — Sat, 25 Apr 2026 15:35:46 GMT

The Paradox of Half-Sovereignty

You’ve paid for a serious VPN. You’ve migrated to Proton Mail. You’ve set up a mesh Tailscale between your Macs. You’ve turned on iCloud’s Advanced Data Protection, disabled half the analytics, switched Safari to privacy max.

Yet your ISP still knows that last night, at 11:47 PM, you opened a tab on a dating site.

Not because your VPN leaked. Not because Apple cracked. Because the most basic layer of the internet, the one everyone’s heard of but no one pays attention to, operates in plaintext by default. This layer is called DNS, and it’s the weak link no one notices, even in otherwise solid privacy stacks.

This article explains why this link is broken, why easy answers like Cloudflare’s 1.1.1.1 and iCloud Private Relay aren’t really answers, and how to regain control in three graduated levels.

What’s DNS?

The directory that makes the internet usable

Humans remember names: proton.me, apple.com, macsouverain.fr. Machines, however, only speak in IP addresses: 185.70.43.10, 17.253.144.10, 83.228.215.109. Between the two, we need a real-time translator. That’s DNS, the Domain Name System.

Imagine a landline phone without a directory. You know the name of your plumber but not their number. So, you first call directory assistance, get the number, then call your plumber back. DNS is exactly like that: an automatic directory assistance service, queried dozens of times per minute, without you even realizing it.

The full flow of a resolution

When you type signal.org into Safari, here’s what happens in a few dozen milliseconds:

Your Mac checks its local cache. Has it asked for this address recently? If yes, it reuses it and that’s it.
Otherwise, it queries the resolver configured on the machine. By default, that’s the one your router pushed via DHCP, so your ISP’s.
If the resolver doesn’t have the answer in cache, it hits the DNS hierarchy. It first queries a root server, one of the thirteen reference addresses of the global directory (deployed on hundreds of physical instances in anycast), which tells it “for .org, ask these servers”.
It then queries the TLD server for .org, which tells it “for signal.org, ask these servers”.
It finally queries the authoritative server for signal.org, which holds the official truth and sends back the IP address.
The resolver sends you the response, your Mac can establish the HTTPS connection.

This descent of the hierarchy is called recursive resolution. The resolver does the climbing for you.

And it’s precisely on this first link, between your Mac and the resolver, that everything hangs.

Why It’s Achilles’ Heel

By default, everything goes in the clear

Classic DNS runs on port 53, using UDP, without encryption. When your Mac asks your ISP for proton.me, the question and answer travel in the clear over the network, readable by any equipment between the two: your modem, the neighborhood DSLAM, the operator’s router, and of course, the ISP’s own DNS server doing the work.

HTTPS doesn’t change that. It encrypts the content of pages, not the DNS query that preceded them. Your ISP already noted the destination before the encrypted connection starts. You can have the best lock icon in the world on Safari, your ISP already knows where you’re going.

Your ISP sees every domain, with timestamps

It’s like knowing every store you visit in a day without knowing what you’re buying. For commercial profiling or judicial scrutiny, that’s more than enough.

A visit to a divorce lawyer’s website speaks volumes. So does a 3 AM visit to a betting platform. Same goes for a morning visit to a specialized medical site. Your browsing data is a goldmine of free data, to sell or exploit.

In France, ISPs are legally required to keep these metadata for a year (decree 2006-358, challenged but maintained despite CJEU rulings). In the US, ISPs have sold browsing histories to data brokers, legally, due to lack of federal protection. The risk isn’t targeted spying in everyday life, it’s structural exposure: data collected automatically, stored for months, accessible on request or via a leak.

Encrypted at ISP ≠ Encrypted End-to-End

Many users think that because their router shows a lock icon in the admin interface or their plan mentions “secure DNS”, they’re protected. Wrong. Your ISP could very well encrypt the link between its own servers and an upstream, but that doesn’t change anything: it’s them who resolve, it’s them who see, it’s them who log.

The only way to keep your DNS query away from your ISP is if it never goes through their servers. Not through them, not through their box, not through their “enhanced” resolver.

And even with a VPN, it can leak

You’ve got a VPN running. All your traffic is encrypted in a WireGuard tunnel. Yet, your DNS queries can bypass the tunnel and go straight to your ISP. That’s a DNS leak, one of the quietest flaws of poorly configured or cheap VPNs.

The mechanism is simple: your device remembers the DHCP resolver of the modem, the VPN doesn’t push its own resolver hard enough, and some system queries go parallel to the tunnel. Your web traffic is protected, your DNS is exposed.

Thirty-second test: dnsleaktest.com or dnscheck.tools. If your ISP appears in the list while your VPN is connected, you’re leaking.

Read: Why You Need a VPN, and What It Actually Does

The DoH, DoT, and Private Relay Trap

Encrypting, yes, but with whom

To answer clear-text DNS, the industry has pushed two protocols: DoH (DNS-over-HTTPS, port 443) and DoT (DNS-over-TLS, port 853). In essence, they do the same thing: encapsulate the DNS query in an encrypted tunnel between your Mac and a resolver. But DoH blends in with normal HTTPS traffic and is harder to identify and block by network admins, while DoT is easier to spot.

Enabling DoH or DoT finally gets your DNS queries out of your ISP’s sight. It’s a real improvement. But we haven’t really solved the problem; we’ve just moved it.

Because the real question isn’t “Is it encrypted on the wire?” It’s “Who’s on the other end?”

Centralization, the other name for snooping

When you enable DoH by default on Chrome, Firefox, or via a generic macOS profile, you typically end up with Cloudflare, Google, or NextDNS. Cloudflare handles a huge chunk of global public DNS. So does Google. Both are American companies, subject to the CLOUD Act, meaning they can be forced by US justice to hand over data, regardless of the user’s nationality.

You’ve replaced one snoop, your ISP, which can be compelled by French justice, with another, an American cloud service that can be forced by the US, no warrant needed, thanks to the 2018 CLOUD Act. The conversation isn’t in clear text on the wire; it’s just recorded elsewhere.

This is where most DNS comparison guides look away. “Cloudflare 1.1.1.1 is free and it’s fast.” That’s true. “It’s private” is a claim that can be misleading and needs to be contextualized by the jurisdiction and business model of the operator.

Apple Private Relay, the premium illusion

iCloud Private Relay, included with iCloud+, is an interesting twist on the same trap. The mechanism: Apple encrypts your DNS queries and Safari traffic, sends them first to an Apple server, then to a partner (Cloudflare or Fastly in most regions). The idea is that no single actor sees both who you are and where you’re going.

On paper, it’s elegant. In practice, two major issues.

First, Private Relay closes DNS at the OS level, for Safari and certain system apps, bypassing what you’ve configured. You thought you were using Quad9? Apple goes through Cloudflare or Fastly for Safari, without asking.

Second, it only covers Safari and a fraction of iCloud traffic. Your Chrome, Firefox, Mail, Slack, Discord, SSH client, terminal, torrent client, third-party apps: Private Relay doesn’t touch their DNS queries.

You’re paying for a “premium” service for partial coverage that shifts trust to an Apple+Cloudflare duo you can’t configure or replace. Apple sees you browsing, Cloudflare sees where you’re going, separately by design, but still two CLOUD Act actors you have no control over. For half the traffic, you’ve gained nothing.

Read: Privacy macOS, the settings to change immediately

What It Changes in Practice

What Your ISP Sees, and Doesn’t See

Without encrypted DNS, your ISP has a complete log: domain, timestamp, frequency, approximate session duration. They can deduce that you visit a banking site every day at 8 AM, that you check a specific medical site every Tuesday evening, that you spend time on alternative news sites, that you connect to signal.org at certain times. They don’t read your messages; they don’t need to.

With encrypted DNS and a trustworthy resolver, your ISP only sees TLS connections to IP addresses. They know you’re using the internet, not whom you’re connecting to first. Some IP addresses are still revealing, but it’s a huge qualitative leap from the default.

What Can Still Be Correlated

Let’s be clear about what’s still exposed even with sovereign DNS.

Server Name Indication (SNI): During the TLS handshake, your browser still announces in plaintext which domain it wants to connect to, so the server can present the correct certificate. This information is readable by network actors, regardless of DNS. The solution is Encrypted Client Hello (ECH). Major browsers support ECH on the client side, but server deployment is lagging. For sites without ECH on the server side, SNI remains readable by network actors.

Destination IP Address: Even if no one reads your DNS and SNI, connecting to a server reveals its IP address. For a service using a large shared CDN (Cloudflare, AWS), the IP address alone doesn’t say much. For a small self-hosted site, the IP address is enough to identify it.

Browser Fingerprinting: This is where it gets more concrete. Your browser passively divulges, when loading any page, a combination of signals: canvas rendering, GPU, installed fonts, screen resolution, time zone, active plugins. Together, they form a unique enough fingerprint to identify you across sites, without cookies, without visible identifiers.

This is the post-cookie tracking technique used by adtech networks and data brokers, Meta Pixel, Google Analytics, and dozens of less visible actors. It works in private browsing. It survives cookie deletion. And it has nothing to do with your DNS resolver: you can use Quad9 encrypted, your browser fingerprint remains readable.

Sovereign DNS is not a magic wand. It’s one layer of protection among others. It plugs the most visible, most systematic, and least noticed gap.

Myths to Debunk

« I have a VPN, so DNS is covered »

Not necessarily. A serious VPN pushes its own DNS resolver and forces all queries through the tunnel. A free or cheap VPN doesn’t do this, or does it poorly. And even with a serious VPN, certain macOS configurations, apps that resolve through their own stack, DHCP fallbacks, can bypass it. Mandatory test at dnscheck.tools.

« DoH equals privacy »

DoH encrypts the pipe. It doesn’t change the nature of the operator on the other end. Enabling DoH by default in Chrome typically means sending your DNS to Cloudflare or Google. Centralization and US jurisdiction are separate issues from encryption, and they don’t disappear with a lock added on top.

« I have nothing to hide »

The classic argument rests on a false assumption: that the problem is what you do. The real problem is what others can do with your data. Several months’ worth of DNS history, cross-referenced with third-party databases, paints a behavioral profile that you don’t control the usage, retention period, or future recipients of. “Nothing to hide” assumes you know all the ways this data could be reused against you. No one does.

« Apple Private Relay is great»

On a subset of Safari traffic, Private Relay improves the status quo. On the rest, it does nothing. And it shifts trust towards Apple + Cloudflare/Fastly with no configurable alternatives. For someone who doesn’t want to touch settings, it’s better than nothing. For someone trying to have a cohesive sovereign stack, it’s a placebo that could give a false sense of security.

« Cloudflare 1.1.1.1 is fast and free»

True. It’s also an American cloud whose business model relies on aggregated network data collection, and it’s subject to the CLOUD Act. For an ordinary user, it’s better than the router’s DNS. For someone wanting to get out of Five Eyes jurisdictions on their privacy stack, it’s a starting point, not the destination.

Take Back Control, at Three Levels

Three levels of engagement, from simplest to most sovereign. Each is a genuine improvement. Choose the one that fits your available time and technical tolerance threshold.

Level 1, Instant Gain, Two Minutes

Switch your macOS system resolver to a respectful operator, using DoH or DoT, via a configuration profile. No app to install, no service to launch.

Concrete Steps:

Choose a resolver. Two serious candidates, accessible without special technical knowledge: Quad9 (non-profit foundation, Switzerland, NLPD jurisdiction) and Mullvad DNS (Sweden, declared no-logs, Cure53 audited infrastructure, transparent operator). Both: a .mobileconfig file, two clicks, done.
Get the official .mobileconfig profile from quad9.net or mullvad.net, depending on your choice.
Double-click the file on your Mac, go to System Preferences > Privacy & Security > Profiles, validate the installation.
Check the result on dnscheck.tools: you should see the chosen resolver, plus your ISP.

Advantage: Two minutes, zero maintenance, instant gain. Your queries are no longer visible to your ISP.

Limit: You’re still entrusting your queries to an external operator. Quad9 and Mullvad have verified no-log policies and independent audits, which is far better than your ISP. But they’re a foundation or a company, not you. For those who want to delegate less, we step up a notch.

Level 2, Local-First with dnscrypt-proxy

Install dnscrypt-proxy on your Mac. It’s a local service that becomes your resolver. It handles DoH, DoT, DNSCrypt protocol, local caching, domain filtering, and especially anti-leak: it intercepts all system queries and forces them into its encrypted tunnel, regardless of what macOS would have done by default.

How it works:

Your Mac requests proton.me. The query goes to 127.0.0.1:53, to dnscrypt-proxy running locally. The proxy encrypts the query and sends it to one or more anycast resolvers (Quad9, Mullvad, community DNSCrypt servers). The responses come back, are cached locally, and serve your Mac. The whole process happens without your ISP seeing anything, and with the option to wake up multiple upstreams to avoid putting all your eggs in one basket.

Concrete Steps:

Installation: brew install dnscrypt-proxy.
Configuration: Edit /opt/homebrew/etc/dnscrypt-proxy.toml to enable DoH, disable clear DNS, choose a list of resolvers (Quad9, Mullvad, non-logging community ones).
Startup: sudo brew services start dnscrypt-proxy. The service registers and starts on boot.
Configure macOS to use 127.0.0.1 as the only resolver (System Preferences > Network > Advanced > DNS).
Check on dnscheck.tools: you’ll see multiple upstreams running, never your ISP, never Cloudflare or Google.

Advantage: 80% sovereign. Your Mac no longer trusts a single operator. You can distribute the load across multiple no-log European resolvers. Built-in anti-leak. Fast local cache.

Limit: One level higher in initial config, about thirty minutes the first time. Minimal maintenance afterwards, updates via brew. You’re still trusting external resolvers, just multiple ones instead of one, and with the ability to change them in two lines of config.

Level 3, Full Control, Recursive Unbound on Personal VPS

Set up your own recursive resolver. No third parties at all. Your Mac queries your machine, which descends the root → TLD → authoritative hierarchy all by itself. No one facing sees the aggregate of your queries: each authoritative server only sees the query that concerns it, with no knowledge of the rest.

How it works:

You have a VPS at a sovereign hoster (Infomaniak in Switzerland, Hetzner in Germany, etc.). On this VPS runs Unbound, an open-source recursive DNS server renowned for the cleanliness of its code. You connect your Mac to this VPS via Tailscale, so through a WireGuard-encrypted tunnel on a private network. You configure your Mac to use the Tailscale IP of the VPS as the resolver. The queries are encrypted in Tailscale, land on Unbound which does the recursive resolution, and come back. And because all your traffic goes through the Tailscale WireGuard tunnel, your ISP only sees encrypted packets going to Tailscale endpoints.

No commercial operator logs the entirety of your queries. The authoritative servers see a European datacenter IP, not your residential IP. The only residual link in the base config: the recursive queries of Unbound leave the VPS in unencrypted UDP. To eliminate this, configure Unbound in forward-tls-upstream mode to Quad9 or Mullvad in DoT (port 853), and the whole path becomes encrypted, your hoster sees nothing more.

Concrete Steps:

Provision a small VPS (1 vCPU, 1 Go RAM, more than sufficient) at a sovereign hoster.
Install Unbound + DNSSEC validation enabled.
Join the VPS to the Tailscale mesh.
Restrict Unbound to only listen on the Tailscale interface, never the public one.
Configure macOS to use the Tailscale IP of the VPS as the only resolver.

Advantage: Maximum sovereignty over DNS. No third-party operators. End-to-end DNSSEC validation. You can add your own filtering lists (advertising, trackers, Apple telemetry, Microsoft telemetry) without relying on an external service. The resolver is yours.

Limit: The barrier is the installation. Count on half a day the first time if you’ve never touched Unbound. Once set up, maintenance is minimal, monthly package update and occasional logs. You pay for a VPS, a few euros per month.

Overkill for most individuals, but consistent when the rest of the stack is already sovereign (mail, drive, password manager, mesh) and the DNS would otherwise remain the last centralized link.

Read: Digital Sovereignty in Practice

What’s Still Exposed, and How to Close It

Sovereign DNS closes the most systematic gap. Three others remain.

Server Name Indication (SNI): During the TLS handshake, your browser announces the destination domain in plaintext. Even with perfect DNS, this info remains readable by network actors, until ECH is deployed server-side.

The destination IP address remains visible. For services behind a shared CDN, the IP alone doesn’t reveal much. For a self-hosted site on a dedicated VPS, it’s enough for identification.

Browser fingerprinting: Canvas, GPU, fonts, timezone create a cross-site fingerprint that adtech uses independently of DNS, and it survives private browsing. Neither sovereign DNS nor Tailscale affects this: it’s an application layer issue, in the browser. The solution lies in Firefox with arkenfox, Brave with its native randomization, or extensions like CanvasBlocker. A separate topic, article coming soon.

The fix for SNI and IP: Tailscale with exit node. All your traffic goes through a encrypted WireGuard tunnel. Your ISP no longer sees DNS queries, SNI, or the destination. Sovereign DNS + Tailscale exit node, that’s the combo closing these two doors at once.

Sovereign DNS alone is the first brick. Sovereign DNS + Tailscale exit node, that’s the truly locked-down network stack. Tailscale’s architecture is the follow-up, and we promise to explain it all in detail in an upcoming article soon.

In summary

DNS is the internet’s phone book. By default on most connections, it works in plaintext, and your ISP sees every domain you visit, timestamped. HTTPS doesn’t change that; it encrypts content, not destination. And a poorly configured VPN can leak DNS outside the tunnel without you realizing.

Easy solutions are just problem shuffling. Enabling DoH by default typically means switching to Cloudflare or Google, American clouds subject to the CLOUD Act. iCloud Private Relay covers Safari and forgets the rest, giving keys back to Apple and Cloudflare for the part it covers. You haven’t removed the snoop, you’ve just swapped it.

Taking control happens in three graduated levels: immediate gain with Quad9 or Mullvad DNS in DoH, two minutes via config profile. Local-first with dnscrypt-proxy on your Mac, native anti-leak, multi-resolvers, in thirty minutes. Full control with Unbound recursive on a personal VPS via your Tailscale mesh, exit node enabled, half-day install, DNS and SNI sorted at once.

Concrete steps:

Test your DNS leaks now at dnscheck.tools. If your ISP or Cloudflare show up and it wasn’t a conscious choice, you know what to do.
Choose an honest level of engagement with your time. Level 1 immediate is better than Level 3 never.
If you already have a privacy stack elsewhere (VPN, Proton, Tailscale), ensure DNS isn’t the weak link revealing what the rest protects.

DNS is the first brick in a coherent network sovereignty. Without it, the rest is partly theater. With it and Tailscale as exit node, it’s a stack truly armored.

Also see

Need tech terms explained? Check the glossary.

NIS2 forces companies to encrypt. CSAR prevents them from really doing it.

Mac Souverain — Sat, 18 Apr 2026 13:46:22 GMT

July Update 2026. The calendar has shifted: on July 9, the European Parliament allowed the renewal of Chat Control 1.0 without the 361 votes needed to block it, despite the majority voting against it with end-to-end encryption explicitly excluded from the text. CSAR 2.0, the one that contradicts NIS2 and is described here, will resume trilogue talks in September: the “May 4” mentioned below is outdated. Details in the radar.

Brussels has a brilliant idea: forcing you to encrypt your data. They also have another idea, less brilliant but more totalitarian: being able to read it whenever they want.

These are not two policies from two different institutions. It’s the same European Commission, a few months apart, signing both texts (yes, it’s possible, I assure you: welcome to Absurdistan).

NIS2 forces you to secure yourself or face sanctions. CSAR 2.0 forces you to leave a backdoor open so they can spy on you cheaply.

And, like any good mess of texts cooked up by our dear European technocrats, under the pressure of our dear politicians, the right hand doesn’t seem to know what the left hand is doing.

Here’s what this means for your digital protection, and why this inconsistency isn’t an accident.

NIS2: The EU finally discovers cybersecurity

The NIS2 directive came into effect in January 2023. It was called NIS1 before, covering around 500 entities in France. NIS2 expands the scope to 15,000-18,000 French entities according to the ANSSI.

It’s no longer just operators of critical infrastructures; it’s any company with 50 employees and €10 million in turnover or assets in the covered sectors. Healthcare, energy, transport, digital, finance. The hospital sector is listed in Annex I as highly critical.

Article 21 is the heart of the matter. It lists ten mandatory measures, including encrypting data in transit and at rest, multifactor authentication (MFA), and setting up secure communications. In plain language: if you handle data in a sector covered by NIS2, encryption is no longer a recommendation, it’s a legal obligation.

The structural novelty of NIS2 is Article 20. Responsibility no longer lies solely with the company; it lies with the physical person in charge. No more scapegoating the CISO, no more “our provider handled it”. The board members are personally responsible for compliance (Doc, if you’re there, your office is going to be busy, I know some executives heading straight for the tranxene).

France, however, is lagging behind (Same as ever, huh?). The deadline for transposition set by the EU was October 17, 2024. We’re approaching May 2026 (try meeting one of your deadlines and we’ll talk), and the text still hasn’t been voted on in the National Assembly. This delay doesn’t exempt anyone: NIS2 obligations are coming, the question is when, not if.

And in the French bill, one article stands out. Article 16 bis of the bill explicitly prohibits imposing forced access in encryption tools. No provider of encryption solutions can be forced to allow imposed access to their tools.

That’s where things get interesting.

CSAR: The EU wants to read what it just told you to encrypt

CSAR, officially the Child Sexual Abuse Regulation, is the other text. For the full details of the mechanism and the political dossier, the article on Chat Control 2.0 explains it all.

You’ll see that while the goal is laudable and one we all share, the methods are more reminiscent of totalitarian practices of the past than of healthy democracy.

The short version:

CSAR would force messaging apps to scan the content of your messages on your device before they’re encrypted. The technical term is “client-side scanning”.

In practice: your message is read on your device before it’s encrypted and sent. In France, allowing a public agent to access the content of a correspondence without authorization is an aggravated offense. Apparently, when you’re the EU, you can do it, and it doesn’t bother you.

End-to-end encryption remains “technically intact” during transport but is circumvented before it applies. Scanning before encryption is encryption for show.

The status of the dossier at the time of publication: the EU Council adopted its position on November 26, 2025. Trilogue talks, the opaque negotiations between Parliament, Council, and Commission where the final text is cooked up, have begun. Next trilogue: May 4, 2026. Formal adoption targeted: July 2026.

The terms have evolved since the first version: “client-side scanning” is now called “risk mitigation measures” in official documents. The packaging is more presentable. The effect on your device remains the same.

The same European Commission that produced NIS2 is pushing CSAR. It’s not a metaphor.

Read: Chat Control 2.0: The EU wants to read your messages before you send them: mechanism, Signal, Proton, and what you can do.

The fundamental contradiction

Put the two texts side by side.

NIS2, Article 21: encrypt data in transit and at rest, MFA, secure communications. Legal obligation, personal responsibility of the director, sanctions for non-compliance.

CSAR: scanning messages before encryption on every device, no judicial warrant, no user notification, for all communications, not just suspicious ones.

The scan reads everything, and an AI decides your fate. False positives are going to be spectacular. Let’s bet that the dawn raid, with or without apologetic platitudes, will be too.

Why these two texts are physically incompatible: to scan content “before encryption”, it must be accessible, at some point, in plain text, by a third-party process. This process creates a mandatory access point: assumed and legalized in the case of CSAR. This provision is totally incompatible with the objectives of NIS2.

This is precisely what French law, in the NIS2 transposition bill, via its Article 16 bis, prohibits imposing on encryption providers.

The same Commission wrote both texts. The commissioner for cybersecurity oversees NIS2. The commissioner for home affairs pushes CSAR. They’re not enemy ministries. In France, it’s the same story: the ANSSI publishes security guidelines, the DGSI reports its needs to its minister, and once again, interests diverge.

The COM(2025)740 final (November 27, 2025), the Commission’s own evaluation report, admits that the system does not allow a demonstrable link to be established between generated reports and actual convictions, nor can it quantify the number of children actually identified through it.

This isn’t external criticism. It’s the institution behind the text acknowledging, in its own balance sheet, the methodological impossibility of validating the tool it wants to impose on 450 million Europeans.

We’re building infrastructure for mass surveillance.

Its pretext doesn’t hold up, given the implemented technique and the unproven results.

What this says about your protection

NIS2 remains a good text. The obligation to encrypt, take cybersecurity seriously, and hold directors accountable are real advances. If you’re in a covered entity, NIS2 will force you to do what you should have done ten years ago. That’s not the problem.

The problem is what this inconsistency reveals about the solidity of your protection.

Individual digital protection cannot rely on the regulatory coherence of institutions. They structurally contradict each other. NIS2 forces you to encrypt today. CSAR wants to make encryption circumventable tomorrow. The law protecting you and the law spying on you can coexist in the same legal corpus with equal formal legitimacy.

What really protects you is technical design, not legal compliance.

Signal can’t implement client-side scanning without breaking its architectural model. That’s why Meredith Whittaker said she’d rather leave the European market than do it. It’s not a stance; it’s a technical impossibility disguised as a political position. Proton works on the same principle.

A tool whose architectural design prevents scanning is protected differently from one that “respects the law in force”. The law can change. Architecture remains. That’s your guarantee.

For entities covered by NIS2, a caveat is in order: this compliance remains mandatory and necessary. Encrypting your data in transit and at rest, implementing MFA, securing internal communications are real obligations with real sanctions if not met.

Implementing them with tools whose design is solid, whose code is audited, whose jurisdiction is favorable, is stacking two layers of protection instead of one. NIS2 and prudent architectural design are not opposed. They should complement each other.

What doesn’t hold up is believing that “NIS2 compliance = complete protection” if CSAR passes. Legal compliance becomes an insufficient safety net when another law creates a breach in what the first one demanded be built.

The French bill’s Article 16 bis, which prohibits scanning in encryption tools, is a real line of defense. The fact that it coexists in the same bill as NIS2 obligations is encouraging. The fact that it’s in political friction with CSAR, pushed by the same Commission, gives an idea of the terrain on which this tension will play out in the coming months.

In summary

Two texts, one institution, two opposing directions. NIS2 forces you to encrypt, holds directors accountable, and in the French bill, explicitly prohibits scanning in encryption tools. CSAR wants to scan before encryption, i.e., circumvent encryption by design, without a judicial warrant, for all your communications.

This isn’t a contradiction that can be overcome with an amendment. It’s a structural incoherence between two institutional priorities that are incompatible: securing and surveilling.

Concretely, the points to watch:

1. If you’re covered by NIS2, get a head start on compliance without waiting for the French vote. Obligations are coming, transposition delay or not.

2. Choose tools whose technical design makes forced access impossible, not just tools that “respect current regulations”. Regulations change. Architecture less so.

3. Follow CSAR trilogue talks: May 4, 2026, is the next turning point. Public pressure worked on Chat Control 1.0.

For a deeper dive into end-to-end encryption and why it remains the only solid bulwark, the upcoming article on the subject will explain.

Read: Chat Control 2.0: The EU wants to read your messages before you send them

If digital sovereignty concerns you beyond just the regulatory framework, the concept is laid out in the foundational article.

Read: Digital sovereignty: What is it, really?

The ANSSI’s dedicated NIS2 page lists the covered sectors and obligations in detail.

Chat Control 2.0: The EU wants to read your messages before you send them

Mac Souverain — Sat, 18 Apr 2026 13:46:19 GMT

JULY UPDATE 2026. The timeline of this article is outdated: the trilogue on May 4th took place, and on July 9th the European Parliament allowed the renewal of Chat Control 1.0 (voluntary scanning), not by a vote for but due to the lack of the 361 votes required to block it, while the majority voted against. End-to-end encryption is explicitly excluded from this text. The real fight, CSAR (2.0) described below, will restart in trilogue in September. Details in the radar.

You send a message to a friend on Signal. End-to-end encrypted, no one can read it between you two. That’s the principle, that’s the promise, that’s what makes hundreds of millions of people use encrypted messaging.

The European Union finds this problematic.

Under the guise of fighting child pornography, the European Commission is pushing a regulation that would force every messaging app to scan the content of your messages before they are encrypted. Signal threatens to leave Europe. Proton says it would rather be blocked. Apple hasn’t said anything. And that might be the most worrying part.

Read: Radar Chat Control 2.0: EU wants to scan all your messages

The Problem: A Snitch on Your Own Device

Imagine a postman who reads every letter you send, compares it to a blacklist, then puts it in a sealed envelope. The envelope is well-sealed, no one can open it in transit. But the postman has already read it.

That’s exactly what the CSAR (Child Sexual Abuse Regulation) would impose on encrypted messaging apps. The technical term is “client-side scanning”. In human terms: your device scans the content of your messages, photos, and files before they are encrypted and sent. The scan result is compared to a database of illegal content. If a match is detected, automatic reporting to authorities.

End-to-end encryption remains “technically” intact. The message is encrypted during transport. Except it’s read beforehand.

Encryption that’s bypassed before it applies is just window dressing.

The Mechanism: How It Works in Practice

Client-side scanning relies on three steps, all performed on your device.

Pre-encryption interception: When you type a message or attach a photo, the content is captured in plaintext before the end-to-end encryption protocol applies. That’s the key to the mechanism: encryption is never “broken”, it’s bypassed.
Perceptual hash comparison: The content is converted into a numerical fingerprint and compared to a database of known content fingerprints. The problem of false positives is well-documented: family photos, medical images, memes have already triggered false reports in existing systems from Google and Meta.
Automatic reporting: If there’s a match, the authorities are notified without human intervention and without notification to the user. You don’t know you’ve been reported. You can’t contest before the process starts.

All this happens silently, in the background, on every message sent by every user. And without any judicial warrant. The door is open to all kinds of administrative abuses.

It’s mass surveillance by design, under the guise of clean democracy.

And that’s where the postman analogy falls short. The postman, you can see. If he gets caught, it’s aggravated offense direct. Likely prison time.

The scanner integrated into your own device, though, it’s just chilling. If you don’t read my articles, you don’t even know it’s just there, working under your nose.

What It Changes in Practice

Two Texts, Two Fates

It’s important to untangle two things that often get confused.

Chat Control 1.0, in its most aggressive form, wasn’t renewed, that’s true. But the reality is more nuanced. On March 11th, 2026, the European Parliament voted 458 to 1 to extend the ePrivacy derogation until August 3rd, 2027. The old derogation expired on April 3rd, 2026. The resolution explicitly protects end-to-end encryption: measures cannot apply to E2EE communications. It’s not “Chat Control 1.0 is dead”. It’s a partial victory: mandatory E2EE scanning is off the table, a limited extension was voted for, and time was given for the permanent CSAR text to be negotiated. Upcoming CSAR trilogues: May 4th and June 29th, 2026.

Chat Control 2.0, officially dubbed CSAR, that’s another story. And it’s that one that’s at stake.

The Council of the EU adopted its position on November 26th, 2025, with Poland and the Netherlands voting against. Since December 2025, the text has been in trilogue: the phase where the final text is crafted between Parliament, Council, and Commission. These negotiations are opaque by design. The positions of the three parties are not public, compromises are made behind closed doors.

Next trilogue: May 4th, 2026. Formal adoption targeted for July 2026.

The terms have changed since the first version. “Client-side scanning” has become “risk mitigation measures” and “voluntary detection activities”. The packaging is more presentable. The practical effect is the same, according to the EDRi, the EFF, and noyb.

Signal, Proton, Apple: Three Very Different Responses

Signal was direct. Meredith Whittaker, executive director, said in October 2025 that Signal would “unfortunately have to leave the European market” rather than compromise its encryption. Signal is a non-profit organization. No shareholders, no advertising revenue, no market obligations. When they say that, it’s credible.

Proton, jurisdiction Switzerland, same stance: “we’d rather be blocked”. Switzerland isn’t in the EU, Proton benefits from real legal distance from European law. The CSAR would only apply to Proton if Proton operates in the EU via its European users, but the legal room for maneuver is wider than just “we comply or we close”.

Apple hasn’t said anything publicly about the CSAR.

This silence is significant. In December 2022, Apple abandoned its own client-side scanning project for iCloud photos after a massive backlash from the security research community. The message seemed clear: no client-side scanning.

Unless Apple isn’t Signal. Apple is a publicly traded company, with physical Apple Stores across Europe, local subsidiaries, European revenue in the tens of billions. Signal can say “we close”. Apple, not so easily.

For a Mac user who uses iMessage daily and trusts its end-to-end encryption, Apple’s silence on the most direct threat to that encryption is the most uncomfortable angle.

The Global Pattern: Same Excuse, Same Infrastructure

Europe isn’t acting in a vacuum.

In the US, the EARN IT Act follows exactly the same logic: same excuse (protecting children from CSAM), same effect (destroying end-to-end encryption), same rhetorical strategy. Who could be against protecting children? No one. That’s precisely why it’s the chosen lever.

It’s not a coincidence. It’s a pattern. On both sides of the Atlantic, legislators are using the most morally unassailable cause to create the infrastructure for generalized surveillance. Once built, that infrastructure doesn’t disappear.

When One Judge Suffices

In March 2026, a New Mexico court ordered Meta to pay $375 million for unfair practices towards minors. In this case, the attorney general presented Meta’s decision to make Messenger end-to-end encrypted by default as a “design choice” that made it harder to transmit reports to law enforcement. The judge followed suit, creating a precedent.

The “design choice” argument is formidable: if this legal angle catches on, every decision to improve user security could become evidence in a future lawsuit. Why add encryption? An attorney could make it “a deliberate tool for protecting criminals”. This logic is legally credible, and it’s just been tested successfully.

This ruling only concerns Meta, in the US. But Apple is also legally exposed on US soil. If this precedent makes waves, the pressure on iMessage will be of a different nature than on Signal. Signal can say “we close” for a geographical area. Apple, not so easily.

When the Commission Admits It’s Useless

The implementation report COM(2025)740, published by the European Commission itself, contains a remarkable admission: it’s currently not possible to establish a clear link between the reports submitted by providers and the convictions handed down, nor to provide a reliable overview of the number of children rescued.

This isn’t a libertarian argument. It’s the Commission, in its own document, acknowledging that the tool it wants to impose on 450 million Europeans has no demonstrable results.

We’re creating an infrastructure for generalized scanning of private communications without being able to prove it protects anyone.

The only guaranteed result is surveillance itself.

The categories are elastic by nature. The infrastructure chosen creates the framework for expansion.

The Limits: Myths and False Evidences

”It’s to Protect Children, So It’s Legitimate”

The goal is legitimate. The means aren’t. Everyone agrees we should fight pedocriminality. But creating a system that scans every message from every citizen to catch a tiny minority of criminals is mass surveillance.

It’s straight out of totalitarian states. The ones that Europe and France love to criticize for their lack of human rights and public freedoms.

And specialists in child protection, including within European civil society, point to targeted alternatives: strengthening law enforcement resources, international cooperation, behavioral detection on non-encrypted platforms. Mass scanning isn’t the only tool. It’s the most intrusive one.

”Encryption Is Protected in the Text”

The CSAR text does contain a clause protecting encryption. But this clause coexists with the obligation to scan content before encryption. It’s like guaranteeing the inviolability of mail while requiring the postman to read it before sealing it.

”It Only Concerns Criminals”

No. Scanning is systematic, applied to all communications, not just suspected ones. There’s no judicial warrant. There’s no targeting. If you use an encrypted messaging app in Europe, your messages would be scanned. All of them.

False positives exist. Similar systems deployed by Google and Meta have reported parents sending photos of their children to their pediatrician. Innocent, scanned, reported.

”Once Voted, the Law Is Irreversible”

Not necessarily. The aggressive version of Chat Control 1.0 (mandatory E2EE scanning) was set aside thanks to citizen mobilization and the European Parliament’s vote. Public pressure changes votes. The trilogue on May 4th, 2026, is the next tipping point, and the text isn’t set in stone yet.

The Political Precedent

The real danger of CSAR goes beyond the technical issue of scanning.

If the European Union, the jurisdiction that invented the GDPR and presents itself as the global champion of personal data protection, normalizes mandatory scanning of encrypted private communications, the signal sent to the rest of the world is devastating.

Every government that dreams of surveilling its citizens’ communications will have a ready-made model, validated by the EU, at its disposal.

I’ve spent the last two years building a sovereign, encrypted, largely self-hosted digital infrastructure. Signal for everyday use. Matrix for internal messages, Proton for emails, encrypted DNS, hardened browsers. By principle, yes, but also for business.

What’s shocking about this text is that it’s pushed by the same institution that created the GDPR. The one that prides itself on all the virtues attached to human rights and freedoms.

Mass surveillance infrastructure never comes with an expiration date. Once in place, it only expands.

The databases for comparison, currently limited to CSAM, could tomorrow include terrorist content, extremist content, disinformation content. Except to be characterized as such today, content must meet precise, legal criteria that a judge must confirm.

Without judicial control, with a little push, we could easily slide into subjects like divergent political views, investigative journalism that ruffles feathers (Rhaaa! Mediapart and Le Canard Enchaîné, thorny issues for elected officials…), the labor sector, NGOs that make too much noise where it hurts, medical confidentiality, etc. All by simple administrative means, without a warrant, and without a judge. Franco must be kicking himself for missing this.

The categories are elastic by nature. The infrastructure chosen creates the framework for expansion.

What You Can Do

You can’t prevent a trilogue from happening. But you can make surveillance more difficult on your own devices, and you can influence the political outcome.

Protect Your Communications

Signal for your conversations. It’s the only messaging app, with end-to-end encryption, whose operator has publicly stated they’d prefer to close the service in Europe rather than compromise its encryption.

Open-source, no advertising, no data collection. Funded by donations, including $50 million from Brian Acton, co-founder of WhatsApp, when the Signal Foundation was created in 2018. No shareholders, no advertising revenue: no financial incentive to monetize your messages.

I use Matrix/Elements because I self-host in maximum privacy mode, but Signal for everyday, easy encrypted messaging is the reference choice. If you had to use only one tool from this list, that’s my recommendation.

Proton Mail for your emails. End-to-end encryption, Swiss jurisdiction, same stance as Signal on the CSAR. Your professional, banking, administrative emails have no business on Gmail, and no one should be able to read them.

Read: Apple Mail vs Gmail vs Proton Mail: The Honest Comparison

Read: Migrating from Gmail to Proton Mail

Reduce Your Exposure Surface

VPN as an additional layer. If Signal or Proton were to be geo-blocked in Europe, a VPN with an IP outside the EU would give you access to the service. Mullvad is the one I’d recommend: no account, no email, cash or crypto payment, Swedish jurisdiction. The VPN doesn’t replace messaging encryption, it complements it by masking your access.

Sovereign DNS. Change the DNS resolvers on all your devices. If European ISPs are forced to block domains, a resolver outside the EU’s jurisdiction circumvents that block. Quad9 (9.9.9.9), run by a Swiss non-profit association, doesn’t log your queries.

To natively encrypt DNS queries on Mac and iPhone, install the DoH profile configuration from Quad9’s documentation page (docs.quad9.net, under Apple). Ten minutes well-spent.

If Signal or Proton Leave Europe?

That’s the practical question. If the law passes and Signal or Proton make good on their threat, how do you keep using them?

Signal distributes its Android APK directly on signal.org. On iOS, the Digital Markets Act, in effect since March 2024, opens the door to sideloading. Signal could distribute its app via an alternative channel, outside the App Store. It’s technically feasible.

Proton is end-to-end encrypted by design: your emails and files are encrypted by default, Proton has no access. Maximum confidentiality by default. If a geographical block were to occur, a VPN with an IP outside the EU would suffice to bypass it. The VPN is also end-to-end encrypted: two independent layers.

Important note: “leaving the market” would first be a negotiation threat, a political signal. Legal recourse would come first. Signal and Proton know this. So do the legislators. It’s a game of pressure, not an immediate ultimatum.

Read: Why You Need a VPN

Weigh In on the Outcome

The trilogue on May 4th, 2026, is the next tipping point. Public pressure works: the vote on Chat Control 1.0 proves it. The aggressive version was set aside thanks to citizen mobilization.

The EDRi (European Digital Rights) and Patrick Breyer, former Pirate MEP and one of the most consistent voices against this text, maintain tools for direct contact with MEPs. Use them. Write to your representatives. It’s not just activism, it’s applied democracy.

The CSAR isn’t voted yet. It’s not dead yet either.

In Summary

The European Union is preparing a regulation that would turn every smartphone into a silent snitch, scanning every message before it’s encrypted. The stated goal is protecting children. The real effect is mass surveillance infrastructure whose effectiveness the Commission itself can’t prove.

Signal and Proton have drawn a line: rather than compromise encryption, they’d leave Europe. Apple hasn’t said anything. For a Mac user who trusts iMessage daily, this silence should raise questions.

Install Signal. Use Proton Mail. Change your DNS. Contact your MEPs before the May 4th trilogue. These are concrete actions you can take today that reduce your exposure whatever happens.

Switching from Gmail to ProtonMail on Mac

Mac Souverain — Thu, 09 Apr 2026 12:15:14 GMT

July Update 2026. The Hide My Email flaw is unmasking Apple aliases (public disclosure on July 1st, still not fixed). Another argument for sovereign aliases: see the email comparison update.

May Update 2026. Another reason to migrate: Proton Mail now offers post-quantum encryption for new emails, included for free. Your communications remain unreadable even by a future quantum computer that stored today’s encrypted versions. Details in the radar.

Gmail is like that roommate apartment where the landlord reads your mail. Not maliciously, just systematically. Since 2004. To show you ads.

Switching to Proton Mail is getting your keys back. Emails between Proton users are end-to-end encrypted, keys generated on your devices, Proton has no technical access. For incoming emails from outside (like from Gmail), Proton encrypts them upon receipt with your public key, and only you can decrypt them. In both cases, Proton can’t read your emails, even if legally compelled.

The migration itself is simpler than it sounds. Allow 30 minutes for a light account, 1 to 2 hours if you have years of Gmail archives. At the end, you’ll have all your old emails in Proton, your contacts imported, and Gmail will automatically forward new messages to your Proton box during the transition.

Read: Apple Mail vs Gmail vs Proton Mail: The Honest Comparison to understand why Proton Mail is architecturally different.

Before You Begin

What you’ll need:

A Mac running macOS 12 Monterey or later
An active Gmail account with IMAP access enabled (enabled by default on most accounts)
A Proton Mail account (the free plan is enough to test; if you have more than 1GB of emails, a paid plan is necessary, see Step 1)
Between 30 minutes and 2 hours depending on your mail volume

What will change:

Your emails will now pass through Proton’s servers (Switzerland), encrypted on the server side
You’ll access your mailbox through the Proton Mail app on Mac (paid, 14-day free trial available) or through the web on mail.proton.me, or through Apple Mail with Proton Bridge (paid plan required for Bridge)
Your new address will be in @proton.me (or @protonmail.com)

What won’t change right away:

Your existing emails on Gmail will remain there until you import them
Your newsletter subscriptions and registered accounts will keep your old Gmail address until you update them manually
You can keep Gmail active in parallel throughout the transition

The operation is entirely reversible. You won’t delete anything at Google at this stage.

Step 1: Create Your Proton Mail Account

Go to proton.me/mail and sign up.

Free plan: 1 address @proton.me, 500MB of base storage (expandable to 1GB by completing the Proton startup checklist), web and mobile app access. Easy Switch is available on the free plan, but the available storage acts as a ceiling for import: with 1GB, you can import about 1GB of old emails.

Plus Mail plan: 15GB of storage, 10 addresses, custom domain support, access to Proton Bridge if you want to use Apple Mail, and SimpleLogin included (an email alias service, more on that in Step 6). Price: $3.99/month (annual billing).

If your Gmail account exceeds 1GB of archives, you’ll need to upgrade to a higher plan or clean up before migrating.

Tip: You can start on the free plan, import the last 12 months, and upgrade to a higher plan if necessary.

Choose your address carefully. firstname.lastname@proton.me for professional use, something shorter for everyday use. You won’t be able to change it later.

Step 2: Import Your Emails from Gmail via Easy Switch

Proton offers a built-in import tool that connects directly to your Gmail account via OAuth, without needing your Gmail password on Proton. Google generates a temporary authorization, Proton uses it to read your mailbox, and that’s it.

In Proton Mail web:

Go to Settings (gear icon at the top right) > All Settings
Click on Import via Easy Switch
Select Gmail
Click on Connect to Google, a Google OAuth window will open
Log in with your Gmail account and authorize the access to your mailbox

Once connected, Easy Switch will display your Gmail folders (Inbox, Sent, Archives, etc.) and let you choose what you want to import. By default, it selects everything: Starred, All Mail, Important, contacts, and calendars.

Path: Proton Mail web > Settings > All Settings > Import via Easy Switch > Gmail > Connect to Google

What you should see: a list of your Gmail folders with message counts, and an estimate of the import time.

Tip: If you have years of archives, the import can take several hours and will run in the background. You can close the tab and come back later.

Recommendation: import the last 12 months first to start using Proton quickly, then come back for the rest.

Step 3: Import Your Contacts

Emails without contacts are half as useful. Google Contacts exports easily.

From Google Contacts:

Go to contacts.google.com
Click on Export in the left sidebar
Select All contacts and the format vCard (.vcf)
Download the .vcf file to your Mac

Path: contacts.google.com > Export > All contacts > vCard format

In Proton Mail web:

Go to the Contacts tab (icon at the top left)
Click on Import
Select the downloaded .vcf file
Confirm the import

Path: Proton Mail web > Contacts > Import > select the.vcf file

What you should see: a summary of the imported contacts, with any detected duplicates to merge.

Step 4: Set Up Proton Mail on Mac

Two options depending on your plan.

Option A: Proton Mail desktop app (paid plan, 14-day free trial)

Download the Proton Mail app from proton.me/mail/download.

It’s an Electron app (like VSCode), not a native AppKit app. It’s not as smooth as Apple Mail, but it handles encrypted emails without any additional configuration.

Warning: the desktop app is only for paid plans. Free accounts get a 14-day trial, after which access is limited to the web version on mail.proton.me.

Launch the app, log in with your Proton account, and you’ll access your mailbox directly.

Option B: Apple Mail via Proton Bridge (paid plan)

If you want to continue using Apple Mail with your encrypted Proton emails, you’ll need Proton Bridge, a tool that translates between Apple Mail and Proton servers by decrypting locally on your Mac.

Proton Bridge is only for paid plans.

Read: Proton Bridge + Apple Mail on Mac, the complete guide with all the setup steps.

Step 5: Enable Gmail Forwarding (optional)

This step is optional but highly recommended during the transition period. It ensures you won’t miss any messages while updating your accounts.

In Gmail:

Open Settings (gear icon at the top right) > See all settings
Go to the Forwarding and POP/IMAP tab
Click on Add a forwarding address
Enter your Proton Mail address
Gmail will send a verification email to your Proton address, retrieve the confirmation code
Go back to Gmail, enter the code, and enable forwarding

Path: Gmail > Settings > See all settings > Forwarding and POP/IMAP > Add a forwarding address

What you should see: your Proton address appears in the forwarding address list with the status “On”.

Tip: Keep this forwarding active for 3 to 6 months. It protects against any forgotten updates while you’re updating your important accounts.

For the Impatient

What this article does: migrate a Gmail mailbox to Proton Mail on Mac without losing any emails, while keeping a temporary forwarding active during the transition. The import is done through Proton’s Easy Switch tool (OAuth connection, no Gmail password needed on Proton).

In practice:

Create an account on proton.me/mail (free to start)
Proton Mail web > Settings > Import via Easy Switch > Gmail > Connect to Google
contacts.google.com > Export > All contacts > vCard (.vcf)
Proton Mail web > Contacts > Import > select the.vcf file
Proton Mail desktop app on proton.me/mail/download (paid, 14-day free trial available) or web version on mail.proton.me (free) or set up Proton Bridge + Apple Mail (paid plan required)
Gmail > Settings > Forwarding and POP/IMAP > Add a forwarding address = your Proton address
Update important accounts in order of priority (banks, admin, services, networks)

Transparency

I use Proton Mail daily, it’s my main email service. The Proton links in this article are affiliate links: if you sign up for a paid plan via these links, MacSouverain earns a commission. That doesn’t change the price for you, and it doesn’t change what I write. If Proton messes up, I’ll say so.

Any technical terms? Check the glossary.

Lockdown Mode, why you should enable it

Mac Souverain — Tue, 07 Apr 2026 09:05:30 GMT

Introduction

In late March 2026, news broke about Coruna, a surveillance toolkit for iOS developed by a U.S. military subcontractor for government agencies. The problem? It had been exploited for four years before being identified. Stolen internally, resold to a Russian broker, it ended up in the hands of Russian spy groups, then Asian cybercriminals specializing in crypto fraud.

The tool exploits dozens of distinct iOS vulnerabilities spread across five full attack chains. It targets iPhones on iOS 13 to iOS 17.2.1, potentially exposing several hundred million devices.

And Lockdown Mode held up against it. The Coruna code actively checks if Lockdown Mode is enabled on the target device, and if it is, it does nothing. No attempt. No bypass. Complete abandonment.

This is concrete, verifiable information that says something important about the security philosophy behind this feature.

The Problem

When a state tool becomes a criminal tool

The story of Coruna follows a trajectory that security researchers have learned to recognize since the Shadow Brokers and the NSA tool leak in 2017: a tool designed for controlled state uses ends up proliferating far beyond its original framework.

Coruna was developed by Trenchant, the spyware and surveillance division of L3Harris, a major U.S. defense company. The tool was intended for government agencies within a strictly defined legal and operational framework.

What wasn’t planned was Peter Williams. The former general manager at Trenchant stole at least eight zero-days from the L3Harris internal system between 2022 and 2025, and sold them to Operation Zero, a Russian zero-day broker, for around $1.3 million in cryptocurrencies and luxury goods. In early 2026, he was sentenced to 87 months in federal prison.

The rest is mechanical: tools move from Trenchant to Operation Zero, from Operation Zero to Russian spy groups, and inevitably, to actors with no operational constraints.

In practical terms: the same framework that was supposed to target specific foreign adversaries ended up in 2025 in watering hole attacks against Ukrainian users (group UNC6353, identified by Google), and later on a network of fake crypto and financial sites targeting any vulnerable iPhone.

The problem that Coruna illustrates

Coruna isn’t a tool thrown together by opportunistic hackers. It’s five years of research and development, with JavaScript obfuscation techniques on four layers, and a chained exploitation of 23 distinct vulnerabilities.

So the real question isn’t whether your iPhone can be compromised. It can be, if you’re using an unpatched version without taking precautions. The real question is how to protect yourself effectively.

The Mechanism

Coruna: how it works

Coruna is what researchers call a watering hole exploit kit. You don’t need to click on a malicious link or open an attachment. You just need to visit a website hosting the malicious code, and your iPhone does the rest on its own.

The kit chains five distinct techniques:

1. WebKit RCE: a remote code execution vulnerability in Apple’s web rendering engine. This is the point of entry. The JavaScript on the site triggers a vulnerability in the WebKit JIT (Just-In-Time compilation) engine to execute arbitrary code.

2. Kernel privilege escalation: from the browser context, Coruna exploits a kernel vulnerability to gain root privileges on the system.

3. System process injection: the malicious code injects itself into legitimate iOS processes, powerd and locationd, to become invisible to common detection tools.

4. Module deployment: from this position, the kit targets over a hundred crypto wallet and exchange apps to exfiltrate private keys and recovery phrases.

5. Persistent C2 communication: communication with the command and control server passes through imagent, Apple’s Messages daemon, to blend in with normal network traffic.

This is precision work.

The response: Lockdown Mode

Lockdown Mode was launched by Apple in 2022 with iOS 16. The promise was explicit: extreme protection for users exposed to state-level threats, such as journalists, human rights defenders, political opponents, and lawyers working on sensitive cases.

The principle is simple but radical: reduce the attack surface as much as possible, even if it means breaking features.

In practical terms, Lockdown Mode disables or restricts:

On the web (Safari and WebKit): the JavaScript JIT compiler is disabled. WebAssembly is disabled. Several advanced web technologies are blocked. Navigation performance drops significantly in benchmarks, sometimes up to 95%. This isn’t a bug. It’s the point.

Messaging: most attachment types are blocked. Link previews are disabled. Incoming calls from non-contacted people are blocked by default.

Networking: automatic connection to unsecured Wi-Fi networks is disabled. 2G networks, historically exploited for attacks, are blocked.

Connected devices: USB accessories require explicit approval, even if the iPhone is unlocked.

The central idea is this: if you eliminate complex parsers, disable dynamic code execution paths, and remove surfaces that aren’t strictly necessary, then most exploits have nothing to latch onto.

Coruna confirms this logic. The kit checks for Lockdown Mode via two specific probes on disabled APIs: IndexedDB and MathML. If these APIs don’t respond, Coruna concludes it’s facing a Lockdown Mode-enabled device and abandons the attack. No attempt at bypass. No Plan B. It leaves empty-handed.

Four years of zero documented compromises

Apple stated at the end of March 2026: “We are not aware of any successful mercenary spyware attack against an Apple device with Lockdown Mode enabled.”

Take this with a grain of salt, as it’s Apple talking. But the claim is independently corroborated.

Donncha Ó Cearbhaill, director of Amnesty International’s Security Lab, confirmed he “hasn’t seen any evidence of an iPhone compromised by mercenary spyware with Lockdown Mode active at the time of the attack.”

The Citizen Lab at the University of Toronto, which has been documenting spyware attacks for years, has confirmed at least two cases where Lockdown Mode actively blocked attacks: one linked to Pegasus from NSO Group, and another linked to Predator from Intellexa.

Four years. Zero documented compromises. Against government-level tools.

Who Lockdown Mode is relevant for

Investigative journalists working on sensitive topics (corruption, organized crime, authoritarian governments).

Human rights defenders operating in contexts where governments have documented the use of spyware against activists (NSO/Pegasus targeted journalists in Morocco, Saudi dissidents, Mexican opponents).

Lawyers working on confidential cases (states, corruption, money laundering, etc.).

Business leaders holding digital assets or sensitive data (cryptocurrencies, patents, client files).

Political activists in countries where the government has a history of using these types of tools against the opposition.

Lockdown Mode imposes some compromises, that’s true. Apple designed it for high-risk profiles, but individual crypto wallet holders also have an interest in activating it, given the rise of stealers targeting macOS.

An honest necessity: the daily frictions

Lockdown Mode isn’t painless. Beyond disabled Safari extensions, there are little things that end up annoying you:

FaceTime: incoming calls from non-contacted people are blocked by default, and even some contacted people don’t get through. SharePlay and Live Photos are disabled.
Broken display on certain sites: with WebAssembly and JavaScript JIT disabled, modern websites (cloud apps, online editors, certain dashboards) display poorly or don’t work.
Navigation slowdowns: some complex sites take several seconds to load where they used to be instantaneous.
Blocked configuration profiles: you can’t install an MDM profile if you need it for work.

I tested Lockdown Mode full-time for a while and ended up turning it off. Not because it’s not effective, it is. But because the frictions accumulate and it becomes annoying in daily use.

The best compromise for the majority: activate it selectively. If you’re a SME director traveling to a high-risk area (professional event, foreign travel, hotel), or connecting to a sketchy public Wi-Fi, activate Lockdown Mode just for the exposed period. Turn it off once you’re back home.

This gives you the best of both worlds: maximum protection when you really need it, comfort the rest of the time.

What the story of Coruna says about the attack surface

There’s a broader lesson in the philosophy of Lockdown Mode that Coruna illustrates: complexity is an attack surface.

The WebKit JIT compiler is a marvel of engineering. It makes navigation fast. It’s also one of the most exploited surfaces in iOS history because it executes dynamic code, which is inherently difficult to secure exhaustively.

Lockdown Mode doesn’t try to make the JIT more secure. It disables it. It’s brutal, and it costs some performance. But it’s effective.

The same logic applies to WebAssembly, attachment previews, and advanced web technologies. Each complex parser is a zone where a bug can become a point of entry.

To understand what Apple Silicon brings to this security philosophy, see Apple Silicon and security: what Secure Enclave really changes.

The Limits

What Lockdown Mode doesn’t do

Lockdown Mode isn’t a universal shield, and Apple is the first to say so.

It doesn’t protect against human errors. If you open a malicious attachment from an app outside the browser, Lockdown Mode doesn’t intervene on this attack vector.

It doesn’t protect against non-web vulnerabilities. Attacks via Bluetooth, vulnerabilities in non-covered system components, or physical vectors remain outside its perimeter.

“No documented compromises” doesn’t mean “impossible to compromise”. The nuance is important. We don’t know what we don’t know. A state actor with a functional Lockdown Mode bypass wouldn’t have any incentive to use it on targets that don’t justify exposing this capability.

It’s not retroactive. If your iPhone was already compromised before activating Lockdown Mode, it won’t disinfect anything.

Coruna and patched iOS versions

The vulnerabilities exploited by Coruna target iOS 13 to iOS 17.2.1, versions released until December 2023. Apple patched most of these flaws in later iOS 17 versions and in iOS 18.

If you’re using iOS 18.x and keeping it up to date, Coruna isn’t directly relevant to you, even without Lockdown Mode. Regularly updating iOS is the first line of defense.

For a complete overview of security and privacy settings to configure on macOS, see macOS Privacy: the settings to change immediately.

In Summary

Coruna is proof that no one is safe. A tool designed for state targets ended up on crypto phishing sites targeting individuals. The proliferation of digital weapons always follows the same path: from targeted to mass.

And it’s an entire ecosystem that’s threatened. It takes Apple years to identify and patch a vulnerability. Coruna exploited 23 simultaneously, spread over four years of iOS versions. By the time patches arrive, the damage is done.

Better to prevent than cure. Lockdown Mode doesn’t fix vulnerabilities, it removes the surfaces they rely on.

Activate Lockdown Mode. Keep iOS up to date. Together, they’re the best defense available today.

The cloud is someone else's computer, so what?

Mac Souverain — Sat, 04 Apr 2026 13:01:48 GMT

Introduction

You’ve got files on iCloud, or Google Drive, or Dropbox. It syncs everywhere, it works, you don’t think about it.

Then you hear this phrase: “The cloud is someone else’s computer.” And you wonder vaguely if you should worry.

The honest answer: it depends. On what you store there, on who that “someone else” is, and on what you’ve agreed to without necessarily realizing it. This article walks through the mechanism, without sensationalizing but without minimizing, so you can make an informed choice, rather than risk making no choice at all.

The Problem

What “cloud” really means

“Cloud” is a marketing term. What it actually means is simple: your files aren’t on your hard drive. They’re on a server, in a datacenter, owned by a company. When you open a document on iCloud from your Mac, your Mac downloads a copy from Apple’s servers, or from cloud infrastructure owned by American companies in Europe if you’re lucky.

The phrase “someone else’s computer” comes from the free software world, used as a dig against centralization. It’s a bit simplistic, but it has the merit of pointing to something real: you’re using a computing resource that you don’t own, that you don’t control, and whose terms of use can change without your consent.

That’s not a reason to stop. It’s a reason to understand.

Three things you’re giving away without thinking

When you put your files on a third-party cloud service, you’re potentially giving away three things.

Access. The company can read your files if they want to, or if someone asks them to. With iCloud without Advanced Data Protection turned on, Apple holds the encryption keys. They can therefore access your photos, your documents, your iPhone backups, and hand them over to a government on request. Apple publishes a transparency report: in their transparency report, Apple indicates that they’ve provided data for the majority of American judicial requests.

Continuity. The company can cut off your access at any time. Violation of TOS (real or algorithmically assumed), bankruptcy, merger-acquisition, unilateral decision. Your files are with them, not with you. The day they shut the door, you pick up what they’re willing to let you take.

Jurisdiction. The laws of the country where your files are stored apply, whether you like them or not. iCloud, Google Drive, Dropbox, OneDrive: all under American jurisdiction, subject to the CLOUD Act of 2018. This law allows the American government to demand access to data stored anywhere in the world if the company is American, without going through the usual international judicial assistance procedures. Even your files in a French datacenter.

The Mechanism

How encryption changes (or doesn’t change) the game

The standard response from cloud providers when you raise this issue: “Your data is encrypted.” That’s true. What matters is who holds the keys.

There are two fundamentally different models.

Server-side encryption (the most common). Your files are encrypted on the company’s servers, with keys that the company manages. That’s better than nothing, it protects against pirates trying to break into datacenters, but it doesn’t protect against the company itself, or a judicial request. iCloud without Advanced Data Protection works this way for most data.

End-to-end encryption, E2EE. The encryption keys are generated on your device, not on the servers. The company stores a file that they can’t read, even if they wanted to, even under judicial order. That’s what Proton Drive does by design. That’s what iCloud does for certain categories of data when you turn on Advanced Data Protection.

The practical nuance: E2EE comes at a cost. If you lose your password AND your recovery key, your data is inaccessible forever. The company can’t help you, because they never had the keys.

What “European jurisdiction” really changes

You often hear “My data is in Europe, so I’m protected by the GDPR.” That’s partially true, and partially false.

The GDPR regulates how your data is collected and used within the European Union. It imposes strict rules on companies operating on the European territory. That’s not nothing.

But it doesn’t protect from everything. If the company is American, the CLOUD Act takes precedence in practice. In 2023, the European Commission adopted the Data Privacy Framework (DPF), a new EU-US transfer agreement meant to replace the Privacy Shield invalidated by Schrems II. It’s already being challenged in European courts and its future remains uncertain. In the meantime, if the data is on European servers owned by an American subsidiary, American authorities can theoretically access it anyway.

Jurisdiction matters. But “servers in Europe” isn’t the same as “company under European law with headquarters outside Five Eyes”. Infomaniak, for example, is a Swiss company, with its servers in Switzerland, under Swiss law. That’s not an absolute shield, but it’s a significantly more protective jurisdiction than the US, and outside the CLOUD Act.

The three levels of trust in practice

To see clearly, here’s how to read a cloud service according to this criterion:

Level 1, You trust the company AND its jurisdiction. You’re using iCloud with Advanced Data Protection turned on: E2EE for most data, except iCloud Mail, Contacts, and Calendar which remain excluded (IMAP/CalDAV/CardDAV interoperability constraints). You’re staying with Apple, under American law. Good for everyday use, insufficient for sensitive data.

Level 2, You trust the encryption, not the company. You’re using an E2EE service like Proton Drive or Cryptomator on top of any cloud: even if the company receives an order, they hand over unreadable files. The weak link here is the code itself. If the encryption is badly implemented, or if there’s a flaw in the application, the E2EE promise doesn’t hold. That’s why two things matter: that the code is open source (anyone can verify what’s running), and that it’s been audited by a third party (Proton Drive has been audited by Securitum, code source published on GitHub).

Level 3, You control the infrastructure. You self-host your own storage (Nextcloud on VPS or NAS, or self-host at home on a server). Zero third-party company in the loop. The weak link here is your own security: a misconfigured Nextcloud or a NAS exposed on the internet is worse than iCloud.

What It Actually Changes

For the individual who wants to do better without reinventing the wheel

If you’re using iCloud today, the first thing to do doesn’t cost anything: turn on Advanced Data Protection (Settings → your name → iCloud → Advanced Data Protection). That switches most of your iCloud data to E2EE (exception: iCloud Mail, Contacts, and Calendar, which remain outside E2EE for interoperability reasons). You keep the Apple ecosystem, you get end-to-end encryption on the rest. The only real downside: if you lose access to your account without a recovery key, Apple can’t help you. You note your key somewhere safe.

If you want to go further without leaving the cloud, Proton Drive is the most accessible E2EE alternative: native Mac app, iOS app, web interface, E2EE by default, audited code. Swiss jurisdiction. It’s not the cheapest option, but it’s the best balance between convenience and sovereignty available without technical expertise.

Coming soon: Proton Drive vs iCloud vs Infomaniak, where to store your files?

For the freelancer with client data

The question becomes business, not just personal. Client data in an American cloud under CLOUD Act jurisdiction is a legal and contractual exposure. That’s not hypothetical, it’s the nature of the applicable law.

The question also becomes legal. Since the Schrems II ruling (2020), storing European clients’ personal data on an American cloud without additional protective measures poses a real GDPR compliance problem. Fines are still rare, but the legal risk exists, and a client could raise it. In Europe, the GDPR applies to any company processing personal data. “iCloud is convenient” isn’t an acceptable response to a client or a supervisory authority.

Pragmatic options: Proton Drive (E2EE) or Infomaniak kDrive, both under Swiss jurisdiction and GDPR-compliant for European companies’ data. Or self-hosted Nextcloud if you have the technical expertise. Article #13 details the differences in depth.

What it doesn’t protect against

Cloud sovereignty doesn’t protect against everything. An end-to-end encrypted file in Proton Drive is unreadable to Proton, but if you open it on a compromised Mac, the decrypted file is there, in plaintext, at the mercy of whatever’s running on your machine. Cloud security doesn’t compensate for poor endpoint security.

Read: Why your email client is a sieve, and how to plug it

And a poorly configured self-hosted Nextcloud exposes more than Dropbox. Full control is also full responsibility.

The real cost of sovereignty is also the price. Proton Drive and Infomaniak kDrive aren’t free. iCloud’s 50GB for €0.99/month is unbeatable. You pay for sovereignty, like you pay for Proton Mail E2EE instead of Gmail. It’s a conscious choice, not an obvious one.

Myths

But Apple’s clouds are in Europe

Apple has datacenters in Europe. That doesn’t change that the parent company is in Cupertino, that the master keys for encryption (outside Advanced Data Protection) are managed by Apple Inc., and that the CLOUD Act applies to American companies regardless of the physical location of the servers.

“Servers in Europe” is a useful marketing argument for local GDPR compliance. Not an argument for sovereignty against a federal American injunction.

Sovereign providers are less practical

That was true in 2018. Proton Drive in 2026 has a native Mac app, automatic folder synchronization, file sharing, and a good web interface. Infomaniak kDrive has a proper macOS integration. It’s not as seamless as iCloud Finder, but the gap has significantly narrowed.

I’ve got nothing to hide

The argument is flawed, not because you have nothing to hide, but because it rests on a incorrect assumption: that the problem is what you’re doing, not what others might do with your data.

Your accounting documents in a cloud readable by third parties isn’t a problem if you’ve done nothing wrong. It’s a problem if your data is used to target you commercially, if it leaks during a breach, exposing client data, or if it’s handed over to a government in a way you hadn’t anticipated.

In Summary

The cloud is indeed someone else’s computer. The question isn’t “should we use it”, but “do we understand what we’re agreeing to by using it”.

Three parameters to look at for any cloud service: who holds the encryption keys (you or the company), what jurisdiction applies (not just the location of the servers), and what happens if the company disappears or cuts off your access.

In practical terms: if you’re using iCloud, start by turning on Advanced Data Protection. If you have professional data, look at Proton Drive or Infomaniak kDrive. If you want full control, self-hosted Nextcloud is the next step, but it requires more technical expertise and maintenance.

The detailed comparison of options, with prices, use cases, and real limits of each, is in article #13.

Coming soon: Proton Drive vs iCloud vs Infomaniak, where to store your files?

Password Manager for Mac: Apple, Bitwarden, KeePassXC or 1Password

Mac Souverain — Wed, 01 Apr 2026 07:58:35 GMT

Introduction

Four options, four radically different philosophies.

The Passwords app (Apple) is free, integrated, and already there. KeePassXC is a local vault, no server, no subscription, no company at the end of the chain. Bitwarden is open source with a free version and self-hostable. 1Password is paid, cross-platform, but proprietary cloud under 5 Eyes jurisdiction.

The right choice depends on one thing: your usage profile and what you’re willing to entrust to whom.

Read: The privacy settings to change on macOS in 15 minutes

The criteria that matter

We keep the useful criteria, not the ones that look good in a table:

Security architecture: Who can technically access your data?
Privacy and jurisdiction: Under what law are your data submitted?
Portability: Does it work on Android, Windows, Linux?
Advanced features: Travel Mode, team sharing, integrated 2FA
Hosting: Third-party cloud or your own
Price: Free, subscription, or one-time purchase
Independent audits: Have the claims been verified?

Not evaluated: themes, number of widgets, and features no one uses.

Apple Passwords app

Philosophy

Apple built its manager around security and ease of use: everything happens on the devices you own, encrypted with your own keys. iCloud sync, passkeys for 2FA, unlock with Touch ID or Face ID, everything is designed to make your life easier.

Strengths

Free and integrated. The Passwords app is available on macOS Sequoia (15.x) and Tahoe (26.x), iOS 18 and iPadOS 18. It manages passwords, credentials, 2FA codes (TOTP), passkeys, Wi-Fi passwords, and secure notes. Nothing to install, nothing to configure, nothing to pay.

End-to-end encryption. With Advanced Data Protection for iCloud enabled, the data in the Passwords app is encrypted with locally generated keys. Apple cannot read it, even if legally compelled. Without this option, some metadata remains accessible to Apple.

Read: Apple Silicon and Secure Enclave: What it really changes

Passkeys. The native integration of passkeys is probably the strongest point in 2026. Passkeys replace passwords with a pair of cryptographic keys: nothing is ever sent to the server. On Mac and iPhone, it works without friction with Face ID or Touch ID.

Family sharing. The app allows creating shared vaults for the iCloud family: personal account credentials on one side, common access (Netflix, Wi-Fi) in the shared vault.

Compromised password detection. Automatic verification via a proprietary Apple system using the k-anonymity protocol: no passwords are sent as is. Apple does not communicate the leak bases used, but the mechanism checks your credentials against known compromises without exposing your data.

Honest limitations

Apple-only, almost. Mac, iPhone, iPad, Apple Watch. On Windows, there is an iCloud Passwords extension for Chrome and Edge, but it’s a crutch. On Android? Nothing. If your setup goes beyond the Apple ecosystem, the Passwords app becomes a real hindrance.

American jurisdiction. Apple is subject to the CLOUD Act, National Security Letters, and American surveillance. Advanced Data Protection for iCloud reinforces technical protection but doesn’t change the jurisdiction.

Limited public audits. Apple publishes white papers but no independent public audit on the Passwords app, unlike 1Password or Bitwarden.

Who it’s for: 100% Apple users, individuals and professionals alike, families.

Price: Free.

KeePassXC

Philosophy

KeePassXC is in a category of its own. It’s not a cloud service, no subscription, no company with servers. It’s desktop software that encrypts a file on your disk. To understand KeePassXC, you need to understand its logic: your passwords are in a file (.kdbx), encrypted, that you store wherever you want. That file is your vault. KeePassXC is the key that opens it.

How it works concretely

On Mac, you install KeePassXC (a .dmg, like any other app). You create a database, a .kdbx file protected by your master password. This file contains all your credentials, encrypted. You store it in a synchronized folder (Nextcloud, NAS, or even iCloud if you want), and KeePassXC opens it on demand. A browser extension (KeePassXC-Browser) automatically fills in your credentials on websites. Touch ID works for quick unlocking.

On iPhone, you install KeePassium, an open-source (GPLv3) app developed in Luxembourg, zero data collection. You point it to your .kdbx file on Nextcloud via WebDAV (your Nextcloud address + your credentials, 10 minutes of setup). KeePassium downloads, caches locally, and synchronizes every time it’s opened. Touch ID and Face ID work for unlocking. You enable auto-fill in iOS settings, and that’s it.

Synchronization is bidirectional. You add a password on iPhone? KeePassium writes to the .kdbx file on Nextcloud. You open KeePassXC on Mac? It detects the change and reloads the database. The same goes the other way around. The file on Nextcloud serves as the synchronization point, always encrypted, whether at rest or in transit.

Strengths

No third-party server, no company, no jurisdiction. The .kdbx file is yours: on your Mac, your Nextcloud, your NAS. No one can access it without your master password because there’s no intermediary in the loop. It’s you who decides where your passwords live.

Open source and certified. KeePassXC is under the GPL license, the code is public. The application has undergone an independent audit in 2023 (Zaur Molotnikov, public report), with positive conclusions on cryptographic protection. Even better: KeePassXC 2.7.9 has obtained the CSPN security visa from ANSSI, recognized in France and Germany (certification on v2.7.9 / Windows 10; the cryptographic architecture is common to all platforms). That’s an official certification, not an audit commissioned by the editor.

100% free, no limits. KeePassXC isn’t freemium: there’s no premium version, no subscription, no feature behind a paywall. The project lives on voluntary contributions and donations. You install, you use, that’s it.

On iOS, it’s KeePassium that takes over. The basic version is free; the premium version (multi-database, automatic unlock) is optional.

Complete features. KeePassXC manages passwords, passkeys (since version 2.7.7), 2FA codes (TOTP), SSH agent integration (agent SSH for your keys), auto-fill via browser extension, support for physical security keys (YubiKey), and compromised password verification via Have I Been Pwned (integrated in the app, k-anonymity request without exposing your data).

Cross-platform desktop. Mac, Windows, Linux. The interface is consistent across the three platforms.

Honest limitations

No Safari extension. Passkeys and auto-fill in KeePassXC work via a browser extension, available for Firefox, Chrome, and Edge. Safari isn’t supported. On Safari, you have to copy-paste from the app (Cmd+B for the credential, Cmd+C for the password, pasteboard automatically cleared). That’s the main limitation for a Mac user.

Austere interface. KeePassXC is functional, not pretty. The interface has been modernized over the years but remains less intuitive than 1Password or Bitwarden. It’s not a deal-breaker, but there’s a learning curve.

No native iOS app. On iPhone, you go through KeePassium, a third-party app, albeit sovereign (open-source, Luxembourg), but it’s an additional software to know. The experience is very good once configured, but it’s not as seamless as Bitwarden or 1Password where everything is integrated.

Natural Travel Mode. KeePassXC doesn’t have a “Travel Mode” button, but the file architecture does better: you have multiple .kdbx files, you choose which ones are on which device. Before a trip, you don’t synchronize the sensitive file to your iPhone, that’s all. And if you use a key file in addition to the master password, you can revoke a device instantly: remove the key file from the device, and even if someone has the .kdbx file, they can’t do anything. That’s the granularity that cloud solutions can’t offer.

Who it’s for: Users with a slightly more technical profile, who don’t want any third-party server in the loop, integration with SSH or YubiKey.

Price: Free.

Bitwarden

Philosophy

Bitwarden is the open-source answer to the problem of cloud password managers. The code is public, auditable by anyone, the business model is honest, and you can self-host if you don’t want to depend on their servers.

Strengths

Open source. The code is on GitHub, under the GPL license. Audited annually by third parties independently (Cure53 in 2018, Fracture Labs in 2024, ETH Zurich in 2025 for cryptography), public reports on bitwarden.com/compliance. That’s maximum transparency for a security tool.

Functional free version. Unlike 1Password (100% paid), Bitwarden has a real free version: unlimited password storage, cross-platform synchronization, sharing with one other person. The Premium version (19.80 $/year) adds 2FA codes (TOTP), security reports (detection of leaks via Have I Been Pwned, weak or reused passwords), and encrypted attachments. Note that KeePassXC offers most of these Premium features (2FA, HIBP verification) for free, but without the integrated cloud sync.

Passkeys and 2FA. Like Apple and KeePassXC, Bitwarden natively manages passkeys. 2FA codes (TOTP) are reserved for the Premium plan (19.80 $/year).

Physical security keys and storage. Since the January 2026 increase, Premium has been beefed up to justify the price. You can now associate up to 10 physical keys (YubiKey, Nitrokey) with your account, up from 2 previously. Encrypted attachment storage goes up to 5 GB. A phishing blocker is also announced, not yet deployed at the time this article is published. For comparison: KeePassXC also supports YubiKey natively, without a subscription, but without the cloud behind it.

Cross-platform complete. Mac, iPhone, iPad, Windows, Android, Linux, extensions for all browsers. Wider than 1Password on Linux support.

Self-hosting. You can run your own Bitwarden server on your NAS or your VPS. In practice, most people self-hosting use Vaultwarden: it’s a community rewrite of the Bitwarden server in Rust (a language focused on security and performance, Apple is even migrating some macOS components to Rust). Vaultwarden is ultra-lightweight, runs on a Raspberry Pi, and remains 100% compatible with the official Bitwarden apps. Your passwords stay on your infrastructure, under your jurisdiction, at your security level. For MacSouverain’s audience, that’s the most sovereign option for a cloud password manager.

American jurisdiction manageable. Bitwarden is based in the US, which is unfavorable in itself. But with self-hosting, the question of the company’s jurisdiction becomes secondary because your data isn’t on their servers.

Read: What digital sovereignty means in practice

Honest limitations

Less polished interface than 1Password. Bitwarden is functionally complete, but the user experience is less polished. It’s not a deal-breaker, but it’s noticeable in daily use.

Self-hosting: installation is the barrier. Hosting Vaultwarden on a VPS or NAS requires initial configuration (Docker, reverse proxy). Once in place, maintenance is minimal: an occasional update, a backup of the database, and it runs on its own. We’ll dive deeper into setting up a complete sovereign infrastructure in our future guides.

Integrated 2FA (TOTP) only in the paid version. The free version doesn’t manage 2FA codes directly in Bitwarden. You need to upgrade to Premium (19.80 $/year) or use a separate 2FA app.

No Travel Mode. Bitwarden doesn’t have an equivalent to 1Password’s Travel Mode.

Who it’s for: Users who want open-source and/or self-hosting, tight budgets.

Price: Free (basic) or 19.80 $/year for Premium (price increase in January 2026, from 10 $/year, with 5 GB storage and support for 10 physical keys in return).

1Password

Philosophy

1Password solves a specific problem: having a reliable, auditable, cross-platform password manager with advanced features for professional use. Its architecture relies on two factors: your master password and a secret key, a 128-bit key generated locally and never sent to their servers. Even if their servers were compromised, your data would be unexploitable without this key.

Strengths

Secret key: a structural difference. The Passwords app mainly relies on your iCloud master password for recovery. 1Password adds a cryptographic layer that can’t be brute-forced from their servers. That’s not marketing, it’s engineering.

Cross-platform complete. Mac, iPhone, iPad, Windows, Android, Linux, extensions for Chrome, Firefox, Safari, Edge. If someone in your entourage has an Android or a Windows PC, 1Password works everywhere without friction.

Travel Mode. If you’re traveling to a country with border controls and you don’t want an inspection to access certain vaults, mark them as “non-travel”, and they’ll disappear from the app until you reactivate them on a trusted device. It doesn’t protect against an extorted password, but it protects against a physical search.

Watchtower. Continuous monitoring via the Have I Been Pwned database (14 billion compromised accounts): passwords present in leaks, weak or reused passwords, sites without 2FA enabled, expired SSL certificates, upcoming expiration dates. That’s the most comprehensive security audit of the four. In comparison, the Passwords app in iCloud detects leaks, weak and reused passwords, functional but basic. Bitwarden offers similar reports (Vault Health Reports) but requires manual generation and has dark web monitoring reserved for the paid plan. KeePassXC only checks strength and duplicates, no built-in leak detection.

Independent audits. Audited regularly by Cure53 between 2020 and 2022 (public reports). Since 2025, annual pentest reports are accessible via the Trust Center of 1Password (access on request). That’s an acceptable level of transparency for a paid security tool.

Team plans. Access management, security policies, activity reports. For an independent contractor managing client accesses or a small team, that’s a real difference.

Honest limitations

Proprietary and paid. 1Password isn’t open-source. You trust their audits, not verifiable code. The individual plan costs 2.74 €/month billed annually (promotional rate for new customers in the first year). Not expensive for a security tool, but not nothing.

Canada, member of the 5 Eyes. AgileBits is based in Toronto. Canada is a member of the 5 Eyes intelligence alliance, along with the US, UK, Australia, and New Zealand. The zero-knowledge architecture limits the risk, but the jurisdiction is still unfavorable compared to Switzerland or a self-hosted solution.

No free version. 14-day trial, then paid.

Who it’s for: Cross-platform users, professionals, frequent travelers, small teams.

Price: 2.74 €/month individual, 4.31 €/month family plan for 5 users (billed annually, promotional rate for new customers in the first year).

Mack’s recommendation

You’re 100% in the Apple ecosystem. The Passwords app does the job, whether you’re an individual or a professional. It’s free, encrypted, has passkeys, family sharing, and especially: Touch ID and Face ID unlock your accounts without friction. Enable Advanced Data Protection for iCloud and you’re set.

You want your passwords to be in maximum sovereignty mode. KeePassXC. Locally encrypted file, synchronization on your Nextcloud, no company in the loop. On iPhone, KeePassium (open-source, Luxembourg) takes over with Touch ID and Face ID. That’s maximum sovereignty on this topic, and the most elegant Travel Mode: you physically control what’s on each device. ANSSI certified.

You want open-source with the self-hosting option, or you’re on a tight budget. Bitwarden. Mostly free, Premium at 19.80 $/year, and Vaultwarden on your NAS if you want full control. Open-source, audited, sovereign if you self-host it. Touch ID and Face ID supported everywhere.

You have devices outside the Apple ecosystem and you need Travel Mode or team management. 1Password does the job technically, and it does it well. The zero-knowledge architecture with the secret key is solid, Watchtower is the best security audit on the market, and Travel Mode is unique. But it’s a proprietary cloud under Canadian 5 Eyes jurisdiction. That’s why MacSouverain can’t recommend it as a privacy solution, despite its undeniable technical qualities.

Transparency: I use the built-in password manager in iCloud daily, it’s my main solution. Bitwarden is the only one here that MacSouverain will have an affiliate link for in the future, and I genuinely recommend it, especially when self-hosted with Vaultwarden.

Read: Why your email client is a sieve and how to integrate a password manager into a complete security posture

Why your mail client is a sieve, and how to fix it

Mac Souverain — Wed, 25 Mar 2026 14:05:23 GMT

Introduction

UPDATE JULY 2026. The Hide My Email flaw is compromising Apple aliases (public disclosure on July 1st, still not fixed). Another argument for sovereign aliases: see the email comparison update.

UPDATE MAY 2026. The mainstream evolution of email encryption: Proton Mail now offers an option for post-quantum encryption, on OpenPGP standard, included for free. The first mail to do so on an open standard. Details in the radar.

The debate on email security keeps going around one axis: “Gmail reads your emails for ads.” That’s true, problematic, and covered everywhere, including the Apple Mail vs Gmail vs Proton Mail comparison.

But even if you migrate to Proton, your mailbox remains an important attack vector. An email is not an inert text file. It’s an HTML document interpreted by a rendering engine of millions of lines of code (WebKit for Apple Mail), loading remote resources, executing CSS, and carrying attachments you’ll open in other software just as complex.

This tutorial covers the six real attack vectors and gives you the exact settings for each. You’ll need a Mac with Apple Mail, 15 minutes, and optionally a Proton Mail account if you want maximum protection. By the end, your email attack surface will be drastically reduced.

Before you start

What you’ll need:

A Mac on macOS Tahoe (26.x), Sequoia (15.x), or Sonoma (14.x)
Apple Mail configured (with or without Proton Bridge)
15 minutes

What will change:

Pixel spies won’t track you
HTML/CSS emails can’t fingerprinter you
Attachments won’t open automatically
You’ll know how to verify if an email is authentic (SPF/DKIM/DMARC)

What won’t change:

Who reads your emails on the server side (that’s the provider’s choice, see the email comparison)
Well-targeted phishing that exploits human trust

Steps

Step 1: Block pixel spies

A tracking pixel is a 1x1 pixel image, transparent, hosted on a remote server, embedded in the HTML body of the email. When your mail client loads the email, it loads the image, sending an HTTP request to the server. This request reveals your IP, mail client, timestamp, and a unique identifier linked to your email address.

In one tiny image, the sender knows you opened their email, where you are, what OS you’re on, when, and how many times. Everyone uses them: newsletters, B2B sales (Mailchimp, HubSpot, Outreach), e-commerce services. It’s legal, almost invisible, and very common.

Until April 14, 2026, at least. The CNIL adopted its recommendation on email tracking pixels on that day. We’ll come back to that later in a dedicated chapter. For now, keep in mind that your “Block all remote content” setting is now aligned with the regulator’s doctrine.

Path: Mail > Preferences > Privacy

Two levels of protection, from least restrictive to most:

Level 1, “Protect Mail activity”: Apple loads images remotely on your behalf via its own servers (proxy). The sender sees Apple’s IP, not yours. Pixel spies are neutralized, but images still load. It’s the minimum.

Level 2, “Block all remote content”: no remote resources load at all. No images hosted on a server, no pixels, no external CSS. The email displays in text and embedded images (CID) only, with no network calls. A “Load remote content” button appears at the top of each email if you want to load on a case-by-case basis.

Level 2 makes Level 1 redundant (if nothing loads, nothing to proxy). But enable both: if you click “Load remote content” on an email, Level 1 takes over and proxies images via Apple instead of loading them directly. Both belts and suspenders.

What you should see: both options checked.

On Proton Mail: active by default, nothing to do. On Proton Mail + Bridge + Apple Mail: the protection operates on the Proton server before even reaching Apple Mail. Still enable the Apple Mail setting above, redundancy is a good practice.

Step 2: Reduce HTML/CSS surface

An email HTML is a web page. And a web page has an execution engine with measurable characteristics that can identify you without cookies and without JavaScript, purely through CSS and HTML.

Media queries can load different resources based on your dark mode, screen size, resolution. Advanced techniques can extract content via CSS alone. Unicode homoglyphs can make phishing URLs visually identical to the original.

Apple Mail no longer offers a global “plain text” toggle on macOS Ventura+. Protection comes from two approaches:

Option 1, block remote content (already done in Step 1): with “Block all remote content” enabled, CSS rendering becomes inert. No external resources load.

Option 2, switch to plain text on a specific email:

Open the email in question
Menu Presentation > Message > Alternative plain text
The email reverts to plain text, no CSS executes

What you should see: emails displayed without rich formatting when remote content is blocked. Plain text option available on a case-by-case basis.

With Proton Mail (web or desktop app), you can enable plain text composition by default for all emails (Settings > Appearance > Compose in plain text). Image and attachment blocking are active by default. What you manually configure on Apple Mail is already set on Proton.

Step 3: Attachments, the habits that matter

Attachments are the most documented malware vector of the past decade. Office VBA macros, PDFs with embedded JavaScript (Adobe Reader executes it by default), TNEF files (winmail.dat) from Outlook.

On older macOS versions, Apple Mail offered an “Open secure attachments automatically” option in Mail > Preferences > General. Apple removed it starting with macOS Sequoia: attachments no longer open automatically. The fact that Apple removed the user’s choice speaks volumes about the risk level it represented.

The setting is set. What’s left is your habits:

Before opening an attachment: press Space (Quick Look) directly from the email. The file displays in read-only without executing.
For PDFs: use Preview (Preview) instead of Adobe Reader, much smaller attack surface.
For.docx /.xlsx from unknown sources: Quick Look first, not Office. Never enable macros in a received document, even from a known source (a compromised account sends credible macros).
A.app,.dmg,.pkg, or.command file received by email? Immediate deletion. No legitimate sender sends an executable by email.

Step 4: Update the mail client without delay

Zero-days on mail clients exist. CVE-2023-23397 on Outlook (CVSS 9.8): a malicious email triggered NTLM authentication towards an attacker’s server without any user interaction. Just receiving the email was enough. Exploited actively by APT28 before the patch.

Apple Mail has a less extensive history than Outlook, but not nonexistent. CVE-2020-9922: Apple Mail could send emails in plaintext even with S/MIME enabled under certain conditions.

Path: System Preferences > General > Software Updates > Automatically install system data files and security updates

Enable everything, including “Install system data files and security updates”. Never delay a macOS update that includes a Mail patch.

What you should see: all automatic update options checked.

If you’re using Proton Bridge: open Bridge > menu bar icon > Check for updates. Bridge has its own update cycle independent of macOS.

Step 5: Learn to verify a suspicious email (SPF/DKIM/DMARC)

Email was designed in the 70s without any authentication mechanism. Anyone can send an email with the From: field they want. Three control mechanisms have been added:

SPF, Sender Policy Framework, verifies that the sending server is authorized for that domain
DKIM, DomainKeys Identified Mail, cryptographically signs the email to verify it hasn’t been modified in transit
DMARC, Domain-based Message Authentication, Reporting & Conformance, ties SPF and DKIM together and defines what to do in case of failure

On Apple Mail:

Open the suspicious email
Menu View > Message > Long headers (or Cmd+Shift+H)
Search for the Authentication-Results: line
Read the three values: spf=pass / dkim=pass / dmarc=pass. A fail or none on DMARC is a high alert signal

What you should see: complete headers with authentication results.

spf=pass dkim=pass dmarc=pass: authenticated email, legitimate sender. All good.

dmarc=fail: the sender doesn’t match the declared domain. Likely phishing. High alert.

dkim=fail: the email was modified in transit or came from an unauthorized server. High alert.

spf=fail alone: less conclusive, SPF configs can be imperfect. Medium alert.

All at none: the domain hasn’t configured any authentication. Maximum caution.

Simple alternative: copy the full headers and paste them on mxtoolbox.com/EmailHeaders.aspx, result readable in 10 seconds.

Important: Apple Mail cannot automatically reject an email that fails. It displays the authentication results in the headers, but filtering happens on the server side, by your email provider. That’s where the choice of provider makes a difference:

iCloud Mail: applies DMARC, but Apple is less transparent about the strictness level. No advanced server-side filters.
Gmail: applies DMARC, but may deliver to spam instead of rejecting. Powerful filters, but Google reads everything in the process.
Proton Mail: applies the sender domain’s DMARC policy on the server side. A dmarc=fail with a reject policy means the email never reaches your inbox. Plus, Proton offers Sieve filters: a scripting language for server-side rules that lets you automatically sort, move, reject, or tag emails based on the sender, subject, headers, etc. Much more powerful than Apple Mail’s rules.

To read soon: Configure Proton Bridge with Apple Mail on Mac

Habit to remember: urgent request + dmarc=fail = phone call before any action, no exceptions.

Step 6: Configure the optimal combination (Proton Mail + Bridge + Apple Mail)

If you want maximum protection on a Mac, the Proton Mail + Bridge + Apple Mail combination stacks three independent layers:

Proton Mail: can’t read your emails (end-to-end encryption, keys on your device), filters pixel spies and remote resources on the server before even transmitting them to you
Proton Bridge: decrypts locally on your Mac, doesn’t transmit anything on the network
Apple Mail: doesn’t execute JavaScript, blocks remote content (if configured as above)

None of these three layers executes active code contained in an email. It’s structurally better than any webmail.

Bridge is available starting with the Proton Mail Plus plan (from €3.99/month on an annual subscription). The free Proton Mail plan doesn’t give access to Bridge.

Try Proton Mail

To read soon: Configure Proton Bridge with Apple Mail on Mac

Pixel tracking: what changes with the CNIL’s April 14, 2026 recommendation

On April 14, 2026, the CNIL adopted its recommendation on email tracking pixels, final after the public consultation of June 2025. It’s not a law or regulation, just a recommendation. But it’s the doctrine that the CNIL relies on to control you and those who write to you. And when the regulator publishes its reading grid, the audits that follow use it.

A tracking pixel, in three lines

A tracking pixel is a 1x1 pixel image, transparent, hosted on a remote server. The sender slips it into the HTML body of their email, invisible to the eye. When your mail client displays the message, it loads the image. This simple load sends an HTTP request to the server, which logs your IP, mail client, timestamp, and a unique identifier linked to your email address.

Result: the sender knows you opened, when, where approximately, what OS, how many times. You haven’t done anything special, you’ve just read. Multiplied by all the newsletters, business B2B emails, commercial notifications you receive, it builds a detailed profile of your attention.

What the CNIL now regulates

The legal basis is Article 82 of the Data Protection Act, which governs cookies and trackers. And the European Data Protection Board’s guidelines 2/2023, which explicitly include email pixels in the category of trackers. The CNIL’s April 14, 2026 recommendation applies this grid to the specific case of pixels in emails.

Principle retained by the CNIL: a tracking pixel is a tracker. It reads and writes information on your terminal (your mail client, your phone, your Mac). Therefore, by default, it falls under the prior consent requirement, like an advertising cookie.

One exception to consent: measuring individual deliverability linked to a service you’ve requested. In other words, for transactional emails, order confirmation, security alert, password reset, account activation, the sender can verify if the email reached you without asking for your consent. It’s seen as a technical component of the service you requested.

Everything else requires explicit consent. Content personalization based on your behavior, marketing audience measurement, targeted advertising, commercial segmentation, fine analytics. If your sender uses the pixel for anything other than verifying that the email arrived, they must ask. Explicitly, at the standard GDPR consent level, not a buried banner at the bottom of a page.

The timeline and what comes next

The CNIL gives three months to comply. In other words: mid-July 2026. After that, audits start. The recommendation isn’t binding in the strict sense, but it’s enforceable in inspection. An audited actor can’t plead ignorance of the doctrine: it’s public, dated, detailed.

And the CNIL has announced inspections. The first ones will likely target big B2C senders, commercial newsletters, e-commerce, media with massive tracking. But the grid applies to everyone: freelancers, SMEs, associations. If you send a newsletter with a Mailchimp pixel measuring opens for marketing purposes without collected consent, you’re off the mark.

What this changes for you who reads your emails on Mac

Nothing to do here. The settings for Step 1, “Protect Mail activity” and “Block all remote content” in Apple Mail, were already the best defense possible before the recommendation. They remain so. The difference: what was presented as “good privacy practice” by geeks is now the regulator’s position. You’re no longer paranoid, you’re aligned with the CNIL.

Proton Mail filters pixel spies by default, on the server side, before the email even reaches your inbox. This option isn’t a gadget: it’s exactly what the CNIL’s recommendation requires as the minimum standard for respecting the reader. Here too, the tool was ahead of the norm, the norm has caught up with the tool.

The only real change on the user side: you can consider that any commercial email that tracks you without having asked for your consent is now in breach. That doesn’t give you much directly, but it gives leverage to advocacy groups, the CNIL itself, and European competitors to the marketing automation giants. The power dynamic has shifted.

And if you’re on the sending side

If you send emails in a professional capacity, association, SME, freelance, independent with a newsletter, the recommendation concerns you directly. Three habits:

Your transactional emails (confirmation, alert, reset) can keep a delivery tracking pixel without consent, as long as it serves that purpose and nothing else.
Your marketing emails, newsletters, campaigns must pass through explicit consent for tracking, separate from the simple opt-in to the newsletter. Reading and accepting to be measured are two separate acts.
Your emailing tools (Mailchimp, Brevo, Sendinblue, Substack) must let you disable the pixel by default or condition it on consent. If your tool doesn’t offer that, you’ll have to change before mid-July.

It’s not the end of emailing. It’s the end of blind emailing, the end of “I open, therefore I’m measured”. For a site like MacSouverain that has recommended since the start the tools that respect the reader, it’s a silent victory.

If it doesn’t work

Problem: emails are unreadable after blocking remote content

Probable cause: the email doesn’t contain a text version, only HTML with images.
Solution: click “Load remote content” at the top of the specific email. The global setting remains active for all other emails.

Probable cause: macOS variant. On some Sequoia/Tahoe versions, the path may differ.
Solution: try View > Message > Custom headers, then check the desired fields.

Problem: a colleague sends winmail.dat files

Probable cause: they’re using Outlook in TNEF mode.
Solution: ask them to send in HTML or plain text. If it’s recurrent, don’t open with non-maintained third-party tools. Quick Look often displays the content.

For the impatient

This article secures your mail client against the six main attack vectors: pixel spies, CSS fingerprinting, malicious attachments, zero-days client, email spoofing, and active code in emails. New since April 14, 2026: the CNIL’s recommendation on pixel tracking makes blocking pixels enforceable in inspection starting mid-July 2026. Your Apple Mail and Proton Mail settings below were already compliant, they remain so.

Concretely, the settings:

Mail Privacy

Mail > Preferences > Privacy > Protect Mail activity = Enabled

… > Block all remote content = Enabled

Attachments & updates

Mail > Preferences > General > Open secure attachments automatically = Disabled

System Preferences > General > Software Updates > Automatically install system data files and security updates = Everything enabled

Verify a suspicious email

View > Message > Long headers (Cmd+Shift+H) → search for Authentication-Results

Maximum protection

Proton Mail + Bridge + Apple Mail (three independent layers, zero execution of active code)

Some technical terms? Check the glossary.

Apple Mail vs Gmail vs Proton Mail, the honest comparison

Mac Souverain — Wed, 25 Mar 2026 14:05:22 GMT

Updated July 2026. The argument “Apple aliases are like SimpleLogin” has gone bust. Researcher Tyler Murphy showed back in June 2025 that you can trace the real address behind a Hide My Email alias. Apple claimed to fix it in March 2026: false. Public disclosure on July 1st (404 Media, picked up by 9to5Mac and MacRumors), the bug still holds, all tested aliases are traceable. A Hide My Email alias doesn’t protect you from someone who really wants to know. A Proton Pass or SimpleLogin alias, hosted outside the ecosystem that’s tracking you, yes.

Updated May 2026. Proton Mail now offers post-quantum encryption for new emails, on all plans including free. Strong differentiating argument vs Apple Mail (PQ3 iMessage silo only) and Gmail (zero). Details in the radar.

You’re on a Mac. You’ve probably been using Apple Mail for years without asking too many questions, or you switched to Gmail because “it’s convenient.” Maybe you’ve heard of Proton Mail and you’re wondering if it’s really worth migrating.

In reality, the question is wrong. These aren’t three competing email clients. They’re three different contracts, with your device, your provider, and your data.

Apple Mail is a client. Gmail is a service (and a data collection ecosystem). Proton Mail is a architectural promise. Understanding the difference is 80% of the decision.

The Three Approaches

Apple Mail + iCloud Mail: Apple makes the client, hosts your emails if you use iCloud Mail. Perfect native integration on Mac and iPhone. Mail Privacy Protection blocks tracking pixels. But iCloud Mail isn’t end-to-end encrypted, Apple can technically access it, and the servers are partly in the US.

Gmail: free service funded by a ad network that’s still over 73% of Alphabet’s revenue (2025). Email isn’t the product, your public profile is. Very powerful, very smooth, US jurisdiction with all that implies.

Proton Mail: fundamentally different contract. Encryption keys are generated on your device. Proton stores your encrypted emails but can’t read them. Swiss jurisdiction, outside 5/9/14 Eyes. Not a marketing promise, real security by architectural constraint.

Apple Mail (+ iCloud Mail)

What You Get

Perfect integration into the Apple ecosystem. Apple Mail natively syncs with your contacts, calendar, Siri, Handoff, Focus Modes. On Mac, it’s smooth. On iPhone, it’s the reference.

Mail Privacy Protection (iOS 15+, macOS Monterey+) masks your IP address from senders and preloads images in the background, so senders see “email opened” but don’t know when or where. Real protection against tracking pixels, on by default since iOS 15.

For iCloud Mail, Apple uses the Secure Enclave on your devices to protect access keys. Emails in transit are encrypted. Apple also introduced Advanced Data Protection for iCloud (opt-in), which extends end-to-end encryption to many iCloud data categories, but not emails, contacts, and calendars for interoperability reasons.

Honest Limitations

iCloud Mail isn’t end-to-end encrypted. Apple can technically access your email content if legally compelled, and the iCloud servers are partly hosted by AWS and Google Cloud, ironically. Apple is subject to US law, National Security Letters, and the CLOUD Act.

Dependence on the ecosystem is real: Apple Mail is excellent if you stay within the Apple world. Connecting a third-party client or automating workflows is more laborious than with Gmail. Advanced features (filters, aliases, multi-domain management) are still limited compared to Gmail or Proton.

Concrete Action

Turn on Mail Privacy Protection: Settings > Mail > Privacy Protection > Hide Mail Activity.

Read: Securing Your Emails for full settings (plain text, block remote content, Bridge configuration).

Gmail: The Service That Knows Everything About You

The Business Model, Clearly

Google is the largest ad network in history. Gmail is free because it funds this ad network, not because Google is philanthropic.

In practice, Google analyzes your emails to:

Extract intent signals (running purchase confirmation, sports equipment targeting)
Feed your Google Ads profile (inferred interests, estimated income, family situation)
Cross with your Search, YouTube, Maps, and Chrome data

Google officially stopped scanning for direct ad targeting in 2017, a voluntary decision to reassure enterprise clients (G Suite). Google already had enough targeting data without needing to read your emails. Metadata is still analyzed: who’s writing to you, when, how often, from which services.

US Jurisdiction: The Legal Problem

CLOUD Act (2018): US authorities can compel Google to hand over data stored abroad, including for European citizens, without going through international judicial cooperation
National Security Letters: secret orders, no prior judicial review, with a gag order preventing you from being informed
5 Eyes: the US participates in the most integrated surveillance alliance in the world

The GDPR applies to Google in Europe in principle. In practice, US-EU data transfers are in permanent legal dispute, and the CJEU has invalidated successive EU-US data transfer frameworks: Safe Harbor in 2015 (Schrems I) and Privacy Shield in 2020 (Schrems II).

Proton Mail: The Different Contract

What End-to-End Encryption Really Changes

Encryption keys are generated on your device, not on Proton’s servers. Proton stores your encrypted emails but can’t read them. Even under judicial compulsion, they can only hand over unreadable text.

What this changes:

Emails between Proton users are only readable by you and the recipient
Proton can’t analyze your content, it simply can’t read it
In case of a server breach, stolen data is encrypted and unusable

What this doesn’t change:

Emails to non-Proton accounts (Gmail, Outlook…) are transit-encrypted but readable on the recipient’s side
Metadata (sender, recipient, timestamp) remains partially accessible
Proton sees when you log in, from which IP address (unless you combine with Proton VPN)
Full-text search is constrained: Proton can’t index what it can’t read. On desktop with Proton Bridge (paid plans), the index is local and improves. On mobile, it’s significantly less powerful than Gmail.
Proton Bridge + Apple Mail: if you’re on a Mac, the Bridge (paid plan) + Apple Mail combination works very well, you keep the native Apple interface with Proton’s encryption underneath. Probably the best of both worlds for a Mac user.

Read: Complete Bridge + Apple Mail Configuration

Swiss Jurisdiction: The Structural Advantage

Proton is headquartered in Geneva. Switzerland is neither in the EU nor in the 5/9/14 Eyes alliances. A foreign access request must go through Swiss diplomatic channels, under control of a Swiss judge. Proton publishes an annual transparency report.

Gmail and iCloud Mail = US = 5 Eyes. Your provider can be legally compelled, secretly, to monitor your account and transmit data to other alliance countries without informing you.

Proton Mail = Switzerland = outside 14 Eyes. Any access request goes through Swiss diplomatic channels, under judicial control. Longer, more transparent, structurally more protective.

Read: Consult the Glossary for the full detail of the 5/9/14 Eyes alliances and the CLOUD Act.

Plain Text, HTML, and Surveillance: The Layer the Comparison Doesn’t Cover

Choosing the right email service is good. Understanding what happens in your inbox before you even read a message is better.

Tracking pixels, HTML/CSS exploits, fingerprinting by formatting: these surveillance vectors work independently of the service you use. Gmail, Proton, or Apple Mail, if you don’t have the right settings, you’re exposed.

Read: Securing Your Emails: What End-to-End Encryption Doesn’t Do Alone

CNIL 14/04: Tracking Pixels Now Regulated

On April 14, 2026, the CNIL adopted its recommendation on tracking pixels in emails. In short: a pixel used to profile, measure, or target you with ads requires your explicit consent. Transactional emails, order confirmations, security alerts, password resets are exempt. Three months to comply, mid-July 2026, then inspections begin.

In practice, who’s already in compliance by default?

Proton Mail blocks tracking pixels server-side before even delivering the email. Always aligned.

Apple Mail with Mail Privacy Protection masks your IP and proxies images via Apple’s servers. Pixels don’t know when you open or where. Active by default since iOS 15.

Gmail lets them through. Google loads images via its own proxy, masking your IP from the sender, but not blocking pixel triggering. Google knows you opened it. The sender too. Google’s compliance needs revisiting, especially for its European Workspace clients broadcasting campaigns without proper consent.

Read: Securing Your Emails: The Full Chapter on the CNIL Recommendation

The Honest Comparison

Apple Mail Free (5GB iCloud), iCloud+ from €0.99/month. Not end-to-end encrypted, Apple can technically read your emails. US jurisdiction, 5 Eyes. Not open source. Native Mac/iOS app excellent, local search solid, Apple ecosystem integration top. No native aliases. Decent privacy.

Gmail Free (15GB), Workspace from around €7/month. Not end-to-end encrypted, Google actively analyzes your emails. US jurisdiction, 5 Eyes. Not open source. Mature iOS + Android apps, excellent search, many integrations. No native aliases. Poor privacy.

Proton Mail Free (1GB), Plus from €3.99/month (annual). End-to-end encrypted, no one reads your emails (keys with you). Swiss jurisdiction, outside 14 Eyes. Open source (clients + crypto). Mature iOS + Android apps, native desktop app free. Limited search (local only). SimpleLogin aliases included from Unlimited. High privacy.

Alternatives to Know

If you want to explore other options without staying in this trio, two names deserve your attention.

Infomaniak K-Mail: Swiss hoster, real European sovereignty, good option for SMEs wanting to leave Google without depending on an American startup. No native end-to-end encryption, but solid jurisdiction.

Tuta (ex-Tutanota): End-to-end encrypted, open source, German jurisdiction (14 Eyes, note). Similar approach to Proton but lighter ecosystem. Consider if you want a Proton alternative.

Conclusion

Staying in the Apple ecosystem: Apple Mail is the rational choice. Turn on Mail Privacy Protection, go plain text, and be aware that iCloud Mail isn’t end-to-end encrypted. Consider Proton Mail for very sensitive emails.

In Google’s orbit: if you use Google Docs, Calendar, Drive, Meet daily, migrating just your email to Proton doesn’t significantly reduce your Google data surface. The question is broader. Proton Mail is a good first step, not a complete solution on its own.

Wanting to leave: Proton Mail is the most coherent choice. Free plan to test seriously. Plus plan at €3.99/month for a truly replacing Gmail use: that’s the minimum viable. Proton’s desktop and mobile clients are solid and independent. If you prefer to stay in Apple Mail, Bridge (included in the Plus plan) lets you use the native interface with Proton’s encryption underneath.

Realistic strategy: start with sensitive uses (banking, health, administrative services), gradually migrate over six months. Not in a weekend.

Try Proton Mail

You manage a team? The question of complete suites (Google Workspace, Microsoft 365, sovereign alternatives) deserves its own article, coming soon.

Technical terms? Consult the Glossary.

Proton Bridge + Apple Mail on Mac: Encryption Without Compromise

Mac Souverain — Wed, 25 Mar 2026 13:50:51 GMT

July 2026 Update. The Hide My Email flaw is leaking Apple aliases (publicly disclosed on July 1st, still not fixed). Another argument for sovereign aliases: see the email comparison update.

May 2026 Update. If you’re using Proton Bridge with Apple Mail, keep Bridge up to date: Proton has enabled post-quantum encryption on the Mail side (manual activation required). Bridge supports it transparently, but a recent version is needed for newly encrypted emails to be readable on the Apple Mail side. Details in the radar.

Proton Mail encrypts your emails structurally, open-source, mathematical, verifiable. You can use it directly via its native app, free on Mac, iOS, and Android. It gets the job done.

But if you want to stay in Apple Mail, with Spotlight, your filtering rules, your keyboard shortcuts, your macOS notifications, you need Proton Bridge. In 10 minutes, you’ll connect Proton Mail to Apple Mail via Bridge. No more web app. Everything in Mail.app, end-to-end encrypted.

You’ll need a Mac on macOS Tahoe, Sequoia, or Sonoma, a Proton Mail Plus (or higher) account, and 10 minutes. At the end, Apple Mail will display your Proton emails natively, with zero-knowledge encryption running underneath.

Read: Why your mail client is a sieve

Before you start

What you’ll need:

A Mac on macOS Tahoe (26.x), Sequoia (15.x), or Sonoma (14.x)
A Proton Mail Plus (or higher) account. The free plan doesn’t include Bridge.
Apple Mail installed (pre-installed on macOS)
10 minutes

What will change:

Your Proton emails will appear in Apple Mail, with Spotlight, keyboard shortcuts, macOS notifications
E2EE encryption is maintained: keys never leave your Mac
Pixel spies and remote resources are filtered by Proton before reaching Apple Mail

What won’t change:

Emails sent to non-Proton addresses (Gmail, Outlook) aren’t E2EE encrypted on the recipient’s side
Bridge uses 150-300MB of RAM in the background
No instant push: Apple Mail polls Bridge (~1 minute)

Warning: If Bridge is closed or crashes, Apple Mail won’t receive anything until it’s relaunched. Make sure Bridge is in your macOS login items and its icon is visible in your active apps menu, top right of your screen.

On the pixel spy protection front, the Proton + Apple Mail combo plays on two fronts. Proton filters tracking pixels on the server side, before emails even reach Bridge. Apple Mail, with “Protect Mail Activity” (Mail Privacy Protection), masks your IP and proxies images via Apple servers for the rest. The CNIL recommendation from April 14, 2026 on tracking pixels makes this double protection enforceable starting mid-July 2026. You don’t need to configure anything extra, both are active by default.

Read: Why your mail client is a sieve, including the CNIL chapter

Steps

Step 1: Download Proton Bridge

Go to proton.me/mail/bridge and download the macOS version. It’s a standard .dmg.

What you should see: a .dmg file in your Downloads folder.

Step 2: Install Bridge

Open the .dmg, drag Bridge into /Applications, launch it. A Proton icon appears in the menu bar.

Important: Allow Bridge to add itself to your macOS login items when prompted. Without this, Bridge won’t start automatically with your session, and Apple Mail will stay silent after each restart.

What you should see: the Proton Bridge icon in your menu bar.

Step 3: Connect to Bridge

Click on the Bridge icon in the menu bar > open the main interface > Connect > enter your Proton Mail credentials > validate the 2FA if you have it enabled (recommended).

Bridge starts synchronizing your emails in the background. Give it a few minutes if your mailbox is large.

What you should see: your account displayed in the Bridge interface, synchronization in progress.

Step 4: Retrieve IMAP credentials

In the Bridge interface: click on your account > Messaging Settings section. Bridge generates a specific password for Apple Mail, different from your Proton password. Copy it.

Also note:

Incoming server: 127.0.0.1, port 1143
Outgoing server: 127.0.0.1, port 1025

What you should see: the IMAP/SMTP settings displayed with a generated password.

Step 5: Add the account in Apple Mail

Open Apple Mail > Mail (menu) > Add Account > Other Mail Account (not iCloud, not Exchange, the generic option at the bottom).

Fill in:

Full Name: your name
Email Address: your @proton.me address (or Proton alias)
Password: the Bridge password you just copied (not your Proton password)

Apple Mail will try to connect automatically, it will probably fail. That’s normal. Click Next to access manual configuration.

Incoming Mail Server:

Server: 127.0.0.1, Port: 1143, SSL/TLS: disabled, Authentication: normal password

Outgoing Mail Server:

Server: 127.0.0.1, Port: 1025, SSL/TLS: disabled, Authentication: normal password

What you should see: your Proton account appears in the sidebar of Apple Mail.

Why SSL disabled? The connection between Apple Mail and Bridge only goes through 127.0.0.1, your own machine, never the network. Bridge handles TLS encryption with Proton servers itself. Enabling SSL on top would create a certificate conflict.

Step 6: Check synchronization

Once the account is added, Apple Mail starts downloading your emails via Bridge. Depending on the volume, this can take a few minutes to a few hours. The Bridge icon in the menu bar shows the progress.

Check three things:

IMAP folders are imported. Your inbox, custom folders, Sent, Trash, Spam should all appear in the sidebar of Apple Mail under your Proton account. If a folder is missing, force a resync: right-click on the account > Synchronize.
Your identities are configured for replying. If you have multiple Proton addresses (aliases, custom domain), check that you can reply from each. Go to Mail > Preferences > Accounts > [your Proton account] > Email Addresses: all your Proton addresses should be listed. When writing an email, the “From:” field offers the choice. If an address is missing, Bridge should sync it normally, relaunch Bridge if necessary.
Test email. Send a test email from another account to your Proton address. If it arrives in Apple Mail, you’re good. Reply to it from Apple Mail to check sending works too.

What you should see: your Proton emails in Apple Mail, all folders visible, all your identities available in the “From:” field, test email received and reply sent.

If it’s not working

Probable cause: Bridge isn’t in the login items.
Solution: System Preferences > General > Open (or Login Items depending on your macOS version). Check that Bridge is listed and enabled. If it’s not, launch it manually from /Applications.

Problem: Emails aren’t sending (SMTP error)

Probable cause: SMTP credentials in Apple Mail are incorrect.
Solution: Mail > Preferences > Accounts > [your Proton account] > Outgoing Mail Server Settings. Check that the server is 127.0.0.1 port 1025, the password is the Bridge one (not the Proton one), and SSL is disabled. If Apple Mail “auto-corrected” the port or enabled SSL during setup, that’s likely where the issue is.

Problem: Sync is slow, emails take too long to arrive

Probable cause: polling frequency is too low.
Solution: Mail > Preferences > Accounts > [your account] > Check for New Messages. Change it to “Every 30 seconds” if your Mac is always plugged in. Note that this slightly increases CPU usage.

Problem: Bridge asks for re-authentication after update

Probable cause: Proton updated Bridge, old credentials are invalid.
Solution: in Bridge, reconnect. New IMAP credentials are generated automatically. Update the password in Apple Mail (account preferences, SMTP section). You don’t need to reconfigure everything, just the password.

Problem: “Can’t connect” at startup

Probable cause: Apple Mail started before Bridge was ready.
Solution: wait a few seconds, then Mailbox > Get All New Messages. Bridge needs a few seconds to start up.

For the impatient

This article connects Proton Mail to Apple Mail via Proton Bridge in 10 minutes. You keep the native macOS interface with Proton’s E2EE encryption underneath. Requirements: Proton Mail Plus account.

In short:

Download Bridge from proton.me/mail/bridge
Install, launch, allow in macOS login items
Connect with Proton credentials
Copy the Bridge-generated password (not your Proton password)
Apple Mail > Add Account > Other Mail Account
IMAP server: 127.0.0.1 port 1143, SSL disabled
SMTP server: 127.0.0.1 port 1025, SSL disabled
Password: Bridge-generated one
Send a test email to check

Try Proton Mail Plus, starting at €3.99/month

Apple Silicon and Security: What Secure Enclave Really Changes

Mac Souverain — Wed, 25 Mar 2026 09:45:11 GMT

Introduction

Apple talks a lot about the security of its chips. “The most secure chip ever designed for a Mac.” “Hardware-level security.” It’s marketing, sure. But for once, rare in the tech industry, the marketing is backed by a serious architectural reality.

This article tears down what’s really happening in an Apple Silicon Mac in terms of security. No soft metaphors from a keynote, no claiming the chip does everything for you. Because it doesn’t do everything, no. But it does what it promises.

The Problem

Before Apple Silicon: The Intel Mess

To understand what Apple Silicon changes, you need to know where we’re coming from.

On pre-2020 Intel Macs, the security architecture relied on separate components:

The main Intel processor handled all the calculations
The T2 chip (on recent models) handled encryption, Touch ID, and Secure Boot, but it was a separate component connected via an internal bus
The Secure Enclave already existed, integrated into the T2, but it communicated with the Intel CPU through a wider attack surface
Memory, storage, CPU, and security coprocessors were separate chips on the motherboard

This architecture is functional. It’s not optimal. Each communication between components is a potential attack surface. And traces on a physical motherboard can be tapped.

For Macs without a T2 (pre-2018): the Secure Enclave didn’t exist at all. FileVault was software-only. It’s a generation to replace if security concerns you.

The Mechanism

Apple Silicon: All on One Die

With the M1 in 2020, Apple changed the game: a System on a Chip (SoC) where CPU, GPU, Neural Engine, memory controller, Secure Enclave, and encryption engines coexist on the same silicon die.

It’s not about convenience. It’s a security architecture decision.

When everything’s on the same chip:

Inter-component communications no longer traverse exposed physical buses
The physical attack surface is dramatically reduced
Memory encryption is handled directly by the integrated memory controller, without passing through an external component
Isolation between domains (kernel, user space, Secure Enclave) is etched into the silicon, not implemented in software

The Secure Enclave: The Safe That Won’t Give You Its Keys

The Secure Enclave is an independent cryptoprocessor inside the SoC. Independent means: it has its own microkernel, its own random number generator, its own memory zone isolated by a dedicated hardware filter, and it shares nothing with the main processor. The encryption keys are managed by the Secure Enclave, while the AES operations themselves are handled by an integrated hardware engine in the SoC’s storage controller.

What it stores and manages:

Biometric Data

Fingerprints (Touch ID): transformed into encrypted mathematical representations, stored in the Secure Enclave, never accessible outside
Face ID (on iPhones, not yet on Macs): same principle, the face data stays in the Secure Enclave

Encryption Keys

The master key for FileVault (disk encryption)
The keys for the iCloud keychain
The keys for decrypting Apple Pay tokens

System Secrets

The UID (Unique ID) key: etched into the Secure Enclave at manufacture, never readable, not even by Apple or you

The core mechanism: the Secure Enclave never gives you its keys. It performs cryptographic operations at your request, but the keys don’t leave. When you unlock your Mac with your fingerprint, the Secure Enclave verifies the match and authorizes the operation, without the raw fingerprint or the encryption key ever leaving the Secure Enclave.

It’s the difference between “hold this key for me and give it to me when I ask” and “use this key for me, I don’t want it”. The Secure Enclave is the second model.

FileVault on Apple Silicon: Encryption Always On

On an Apple Silicon Mac, FileVault uses XTS-AES-256 encryption accelerated by hardware.

Encryption is permanent. Internal storage is always encrypted at the hardware level, even if FileVault is turned off in preferences. What FileVault does on top is protect the decryption key behind your user password. Without FileVault enabled, the key is accessible at startup. With FileVault, the key is wrapped in another key derived from your password + the Secure Enclave.

Remove the SSD, it’s useless. The decryption key is tied to the chip + password pair. An SSD removed from an Apple Silicon Mac is unreadable on another machine because the other machine’s Secure Enclave doesn’t have the right UID key. Even Apple can’t recover these data.

Performance. Encryption/decryption happens in the integrated memory controller. Zero impact on performance. You have no reason to disable FileVault on Apple Silicon.

Practical note: if you lose both your password and your FileVault recovery key, your data is permanently lost. That’s not a bug. That’s correct encryption implementation.

Secure Boot in a Chain

Apple Silicon implements a chained boot process where each link verifies the next:

BootROM (immutable, on the chip)
    → verifies → Low-Level Bootloader (LLB)
        → verifies → iBoot
            → verifies → macOS kernel
                → verifies → system extensions

The BootROM is the absolute anchor. It’s physically etched into the chip at manufacture, impossible to modify, impossible to flash, impossible to logically corrupt. It’s the root of the entire trust chain.

The Three Security Modes

macOS offers three levels in the Startup Options (hold the power button at startup on Apple Silicon):

Full Security (default): only the version of macOS signed by Apple. That’s the mode for 99% of users.

Reduced Security: macOS + signed third-party extensions. For developers, kernel hackers, virtualization tools, security solutions like Acronis.

Permissive Security: everything, including unsigned code. For security researchers and kernel hackers.

These three modes control what’s allowed to touch the macOS kernel. The kernel is the heart of the system: it manages memory, processes, hardware access. A malicious software that installs at the kernel level has total control over your machine, invisible to traditional antivirus. That’s why Apple locks down so tight by default.

The default is Full Security. If you don’t have a specific reason to change it, don’t change it. Certain security software like Acronis Cyber Protect need kernel extensions to function (low-level disk access for backup, real-time surveillance), which requires switching to Reduced Security. That’s a reasonable compromise: you open the door to signed extensions to reinforce your security from another angle.

The difference with Intel: on old Macs, changing the security mode required a firmware password. On Apple Silicon, it’s linked to the Apple ID tied to the machine, adding another layer that ties the machine to an identity.

KIP and PAC: Kernel Protections

Two lesser-known protections that close entire classes of attacks:

Kernel Integrity Protection (KIP) prevents any modification of the macOS kernel while it’s running. Even with root access, even with elevated privileges: the kernel code in memory is protected from writing by the hardware. An entire category of attacks that involved injecting malicious code into a Mac’s running kernel is structurally impossible on Apple Silicon.

Pointer Authentication Codes (PAC) is an ARM architecture feature that Apple has aggressively implemented. Each function pointer is cryptographically signed. Before using a pointer, the processor verifies its signature. If someone’s modified it to redirect execution to malicious code, the verification fails and the system crashes cleanly. That blocks ROP (Return-Oriented Programming) and JOP (Jump-Oriented Programming) attacks, two of the most used exploitation techniques since 2000.

What It Actually Changes

Real-life Scenarios

Scenario: theft. The thief disassembles the SSD and connects it to another Mac: unreadable. They try to reactivate the machine: blocked by the Activation Lock, tied to your Apple ID. They send the SSD to a specialized lab: unreadable, the UID key is tied to your Secure Enclave, not the SSD. Your data is cryptographically dead to anyone without your password.

Scenario: judicial request. An authority asks Apple for access to your data. Apple can’t provide it, structurally, not legally. The decryption key isn’t on their servers. It’s in your Secure Enclave, tied to your password. It’s a technical impossibility.

Scenario: raid. Machine seized while running, session locked: inaccessible without your password. Machine powered off: the SSD is inert without the correct Secure Enclave + password.

What that implies in return. If you lose both your password and your FileVault recovery key, your data is permanently lost. That’s not “hard to recover”. Lost. That’s the direct consequence of this level of security.

No Equivalent Among Competitors

On Windows, BitLocker stores a copy of the recovery key on Microsoft’s servers by default, meaning a judicial request to Microsoft could succeed. On standard PCs, hardware encryption depends on the manufacturer’s implementation, with huge variance in quality. On Linux, dm-crypt is solid but requires explicit configuration, it’s not active by default.

Apple Silicon is currently the only major manufacturer to offer this level of hardware encryption by default, without third-party software, without additional configuration, without performance degradation, and with an architecture that makes data recovery impossible even for Apple itself.

macOS Tahoe / Sequoia: What’s Changed in Security

Tahoe (26.x) is the current version of macOS since September 2025, currently at 26.4. The points below apply to Sequoia and Tahoe.

Apple Intelligence on-device

Apple’s language models run entirely on the Neural Engine of the chip, in a sandboxed environment separate from the rest of the system. When Apple says “private cloud compute” for heavier requests, it’s an advanced architecture where requests are encrypted in transit, processed in secure enclaves that even Apple can’t inspect, and deleted after processing. Apple admits that end-to-end encryption isn’t possible for this type of remote calculation, the model relies on cryptographic verifiability and public auditing of the server code. It’s not like sending your request to OpenAI.

Lockdown Mode strengthened

The extreme security mode for high-risk users has received additional restrictions on system APIs accessible to apps and on network features. Not relevant for daily use, but good to know if you’re working in a high-risk context. Basically, Western journalist on assignment in China, or US whistleblower.

System Integrity Protection (SIP) evolves

SIP continues to strengthen. On Tahoe, several additional system paths are protected from writing, even root can’t modify these folders without disabling SIP at startup (which requires physical access to the machine).

The Limits

The Secure Enclave and Apple Silicon architecture are impressive. They don’t do everything.

The Network. Your chip doesn’t know what’s happening on your network. An unsecured DNS reveals every site you visit to your ISP, even on an M4 Mac. A VPN and encrypted DNS are still necessary.

Read: Why You Need a VPN

Third-party Apps. An app you download and give permissions to can collect whatever it wants within its scope. The Secure Enclave protects what it controls. It doesn’t control what the Weather app does with your location.

Social Engineering. Your iCloud credentials entered on a clone site of the Apple page, that’s your problem. The most secure chip in the world can’t do anything about that.

An Unattended Mac. Encryption protects data at rest, when the Mac is powered off or locked. Once unlocked, data is accessible.

Default System Settings. The hardware architecture is solid. The software settings, less so, as seen in the article Privacy macOS. The best SoC in the world with Siri listening in and analytics enabled, it’s a nice car with the windows open.

In Summary

Apple Silicon is a real security advancement at the hardware level. The integrated SoC, the isolated Secure Enclave, the boot chain verified from an immutable BootROM, KIP, PAC: these are serious architectural protections that close entire classes of attacks. For an independent or small business handling client data, payments, sensitive information, switching to Apple Silicon is a rational security decision.

But hardware isn’t everything. It creates the foundations. Software configuration, network habits, and access management, that’s what you build on top. Great foundation + cardboard walls = cardboard house anyway.

Secure Enclave: protects your biometric keys, FileVault, Apple Pay. Limitation: doesn’t cover third-party apps.

FileVault + Secure Enclave: protects against theft and physical seizure. Limitation: useless if the machine is unlocked.

Secure Boot: guarantees integrity at startup. Limitation: doesn’t protect running apps.

KIP: blocks kernel modifications. Limitation: doesn’t cover application vulnerabilities.

PAC: blocks ROP/JOP attacks. Limitation: complicates exploitation, doesn’t eliminate it entirely.

Lockdown Mode: software layer that complements hardware protection by disabling most exploited attack surfaces (JIT WebKit, WebAssembly, complex parsers). Available on macOS since Ventura and iOS since iOS 16. To date, zero documented compromises by mercenary spyware on a device with Lockdown Mode active. Limitation: sacrifices performance and certain features to reduce the attack surface. Details in our dedicated article.

Memory Encryption: protects against cold boot attacks on RAM. Limitation: doesn’t protect against logical software access.

Technical terms? Check the glossary.

What's digital sovereignty and how to practice it

Mac Souverain — Tue, 24 Mar 2026 17:41:41 GMT

Introduction

The term “digital sovereignty” can sound scary. You might think of conferences in Brussels, debates on the European cloud, 300-page reports that no one reads. And yes, that exists. But it’s not what directly concerns you.

What concerns you is the everyday version of the problem: who has access to your files, who can read your emails, and what happens when a service you rely on closes or decides you’re no longer welcome. This article sets the stage, jargon-free.

The Problem

What you delegate without knowing

Let’s take a concrete example. You use Gmail. It’s free, it’s convenient, it works.

Here’s what you agreed to by checking “I accept the terms”:

Google analyzes your emails. For years, Google scanned the content of your messages to target ads. They stopped in 2017, not because they had to legally, but because they had enough data elsewhere. Your emails remain analyzed by their algorithms (spam, AI, automatic sorting), stored on their servers, and subject to American law.
Google can close your account. For violating terms of service (real or supposed), prolonged inactivity, or an algorithmic decision. Forums are full of stories of people who lost access to 15 years of emails overnight. With only a complaint form and a bot wishing you a good day as recourse.
Google is subject to American law. A federal court, a National Security Letter, a FISA request, and your data is accessible to the American government. Without any obligation to notify you.
You don’t have a backup. If you don’t make one yourself, your emails exist in only one place: Google’s servers. If access is lost, everything is lost.

And Gmail is just one example. Replace it with Google Drive, Dropbox, Slack, Notion: the pattern is the same. You use a service without controlling the conditions.

Small nuance: not all providers are the same. Apple, for example, allows for end-to-end encryption of iCloud via Advanced Data Protection (which needs to be manually enabled), and its business model relies mainly on hardware and services, even if its advertising revenues are growing. It’s better than Google on privacy. But your data remains on their servers, subject to American law, and Apple can still disable your account. Better doesn’t mean truly sovereign.

Three questions to ask about each of your tools

For an independent or small business, digital sovereignty boils down to three questions:

Who controls your data? You, or a provider who could change their terms tomorrow?
Where are they stored? In a jurisdiction that protects your privacy, or in a country where a government can demand access without notifying you?
What happens if the service closes or cuts off your access? Do you have a Plan B, or is it total shutdown?

If you can’t answer these three questions for each of your critical tools - email, storage, passwords, communication - then you’re not sovereign. You’re a tenant. With a lease that can be terminated without notice.

The Mechanism

Sovereignty is a spectrum

No one is 100% sovereign. It’s neither realistic nor necessary. The goal isn’t to self-host everything in a submarine: it’s to make conscious choices.

There’s a spectrum:

Level 0, all with GAFAM. Gmail, Google Drive, Chrome. You control nothing, you pay nothing in cash. In fact, your data is the product. It’s not encrypted, your provider can read it, and they can be forced to hand it over to a government without even notifying you. And it’s not just Google: Microsoft with Outlook and OneDrive, Amazon with Alexa, same pattern. Servers you don’t control, and a right to look into your digital life that you gave up with one click, because their terms were written to confuse you. As for Meta, WhatsApp encrypts your messages, but collects who you call, when, and where. The content is protected, but the rest of your digital life, much less so.

And if you’re all Apple? It’s a significant step up. Apple doesn’t live off your data and takes privacy more seriously than its competitors. Advanced Data Protection encrypts a lot of iCloud end-to-end, but not everything: Mail, Contacts, and Calendar remain accessible on the server side. And above all, your data is on servers subject to American law, and you entrust everything to a single provider. If your Apple ID gets blocked, even temporarily, it’s email, photos, passwords, and apps that become inaccessible all at once.

Level 1, privacy-first alternatives. You migrate to services that respect your privacy by design. Proton Mail instead of Gmail. Proton Drive or encrypted storage instead of Google Drive. A dedicated password manager instead of the browser’s password manager. Brave or Firefox instead of Chrome. A VPN so your ISP stops profiling your browsing. You’re still hosted, but by providers whose business model aligns with privacy and your interests, not against them.

Level 2, mastered hybrid. You keep control of what’s critical: NAS for your files, Nextcloud for collaboration, local password manager. For what requires high availability, you choose trusted third parties aligned with privacy: Proton for email, an European host for encrypted multi-site backup. You control your DNS, you have a VPN, and you know exactly where each piece of data lives.

Level 3, complete infrastructure. Dedicated server or VPS, secure mesh network, self-hosted files and messaging, all end-to-end encrypted. Your backups are distributed across multiple geographic sites. You no longer depend on anyone to access your data, and if a data center burns down, everything is replicated elsewhere. That’s what I do. It’s excessive, perhaps, for most individuals, but desirable for an entrepreneur concerned about business continuity.

The right level is the one that corresponds to your real risk and the time you want to spend on it. For most independents, level 1 is a massive improvement. Level 2 is ideal. Level 3 is real security for business.

The concrete pillars

Email. It’s the entry point for everything. Your email is your online identity, your account recovery key, your primary communication thread. The minimum: a provider that encrypts end-to-end, based in a solid jurisdiction. Proton Mail is the obvious choice, E2EE, based in Switzerland, open source, audited by third parties. Tuta (formerly Tutanota), based in Germany and open source, is a credible alternative.

Read: Apple Mail vs Gmail vs Proton Mail, the honest comparison

VPN. Not to “become totally anonymous”, but to prevent your ISP from profiling your browsing and protect against malicious acts on public networks.

Read: Why you need a VPN and how to choose one

Storage. Your files must be encrypted and under your control. iCloud with Advanced Protection enabled is already end-to-end encrypted: it’s a good start if you’re in the Apple ecosystem. To go further: Proton Drive (native E2EE, Swiss jurisdiction) or your own NAS with remote backup.

Passwords. A dedicated manager. Apple’s built-in Passwords app (introduced with macOS Sequoia) is already a good starting point, encrypted, integrated, free. But if you want multi-platform or team sharing, consider 1Password, Bitwarden, or KeePassXC.

Private network (mesh network). If you work from multiple locations or have a NAS, a server, distributed machines, you need to connect them securely. A mesh network like Tailscale creates a private, encrypted network between all your devices, wherever they are.

DNS. The weak link that everyone forgets. Your DNS queries pass in plaintext by default, your ISP sees every site you visit. DNS-over-HTTPS (DoH), DNS-over-TLS (DoT), or local DNS changes everything.

What It Changes in Practice

Where to start

If you’re starting from scratch, here’s the order that makes the most difference with the least effort:

Lock down macOS. 15 minutes, zero tools to install. -> Privacy macOS: the settings to change immediately
Install a VPN. One app, one click. -> Why you need a VPN and how to choose one
Migrate your email. The biggest task, but the most impactful.
Manage your passwords. A manager + unique passwords everywhere.
Take back control of your files. Encrypted storage + backup.
Connect your machines. A mesh network to access everything, everywhere, securely.

Each step is an article on MacSouverain. You progress at your own pace.

What it protects (and what it doesn’t)

Digital sovereignty doesn’t protect you from everything. It doesn’t protect against a weak password, well-targeted phishing, or human error. It doesn’t guarantee that your privacy-first providers won’t ever go bankrupt or change their terms.

What it does: it reduces your dependence on a single provider, increases your ability to react if something goes wrong, and gives you a decision-making framework for every tool you add to your stack.

The Limits

It’s not excessive

There’s a trap to avoid: sliding into total paranoia. Wanting to self-host everything, refusing all third-party services, spending weekends configuring servers to replace tools that worked perfectly well.

Digital sovereignty is a slider, not a switch. Moving it from “zero control” to “reasonable control” makes a huge difference. Moving it from “reasonable control” to “operational paranoia” has diminishing returns.

Compromises are inevitable

You’ll probably still use some cloud services. The important thing is knowing which ones, why, and having an exit plan. Using iCloud for your vacation photos is an acceptable compromise. Storing your business contracts exclusively on Google Drive without a local backup is an uncontrolled risk.

Technique isn’t everything

The best encryption in the world doesn’t protect against a collaborator sending a sensitive file on WhatsApp. Digital sovereignty includes a human dimension: raising awareness, training, defining clear rules.

In Summary

Digital sovereignty isn’t a political concept for Brussels conferences. It’s a very practical approach: knowing where your data is, who can access it, and what happens if things go wrong. It’s practiced in progressive levels, from the simplest (migrating to an encrypted email provider) to the most advanced (self-hosted infrastructure).

Your data, clients, invoices, contracts, exchanges, are the heart of your business. Leaving them in the hands of a third party without a backup or Plan B is like leaving the keys to your office in the lock when you leave at night. It’ll probably work. Until the day it doesn’t. Start at level 1: it’s already a massive improvement. The rest will come naturally.

Technical terms? Check the glossary.

Why you need a VPN and what it actually does

Mac Souverain — Tue, 24 Mar 2026 12:16:03 GMT

Open your Mac. Launch Safari. Go to any site. While the page loads, your ISP logs the domain, the time, your IP address, and the amount of data exchanged. Not out of curiosity. Because that’s how the network works, and in most jurisdictions, it’s allowed or required.

A VPN doesn’t make you invisible. It doesn’t turn your Mac into a digital fortress. But it solves a specific, real problem: preventing third parties from snooping on your browsing and potential malicious activities without your knowledge. This article explains how, why, and especially where it stops.

The Problem

Your ISP Sees Everything (Almost)

When you type a URL into your browser, here’s what your ISP sees, even if the site uses HTTPS:

Your IP address, which is basically you, at your physical address
The domain you’re visiting. DNS resolution happens in the clear on most networks (Chrome and Firefox can encrypt DNS via DNS over HTTPS, but it’s not universal, it depends on your configuration and region)
The time and frequency of your connections
The amount of data exchanged

HTTPS encrypts the content of pages. Not the metadata. And metadata is often more revealing than content itself. Regular calls to a labor law specialist lawyer say more than the conversation itself.

In Europe, ISPs keep this metadata for several months to two years, depending on the country. In France, the law requires a one-year retention period (a controversial framework at the European level but maintained in France). In the US, in 2016 the FCC adopted rules requiring ISPs to protect your browsing data. In 2017, Congress repealed them before they took effect. Result: no obligation to protect, ISPs do what they want with your metadata. It’s not a dystopia, it’s the legal framework in effect.

Public Wi-Fi is Worse

At a café, hotel, airport: the network isn’t owned by someone trustworthy. Anyone on this network, or its manager, can observe the domains you’re visiting, launch man-in-the-middle attacks on poorly configured connections, or serve you a fake captive portal that looks exactly like your bank’s page.

HTTPS protects content. Not your IP address. Not the domains you visit. And not against a malicious Wi-Fi access point that mimics the “Starbucks_Free” network nearby.

It’s Not Paranoia

If you’re self-employed, freelance, or run a small business, your browsing habits reveal your clients, suppliers, strategic research, and legal concerns. It’s intelligence economics served on a platter. For free.

Read: What Digital Sovereignty Means in Practice

The Mechanism

How It Works

A VPN (Virtual Private Network) creates an encrypted tunnel between your device and a remote server. All your internet traffic goes through this tunnel before reaching its destination.

When you connect to a VPN:

Your Mac establishes an encrypted connection with a VPN server (located in the country of your choice)
Your DNS requests and web traffic travel inside this tunnel, unreadable to anyone between you and the server
The VPN server makes requests on your behalf to the sites you’re visiting
The sites see the IP address of the VPN server, not yours

Simple analogy: instead of sending a letter with your name and address on the envelope, you hand it to a trusted intermediary who re-sends it from their own office. The recipient gets the letter, but they don’t know where it’s from. And the mail carrier who transported it between you and the intermediary can’t open it, it’s sealed.

Protocols: Not All Equal

Under the hood, a VPN uses an encryption protocol. The three you’ll encounter:

WireGuard, the modern standard. Minimalistic code (a few thousand lines), fast, auditable. That’s what you want.
OpenVPN, the veteran. Reliable, proven, but heavier (tens of thousands of lines) and slower than WireGuard. Still very common.
IKEv2/IPSec, supported natively by macOS, making it a solid choice on a Mac without installing third-party apps. Stable, quick to reconnect when you change networks.

The trend is clear: WireGuard is becoming the reference protocol. If your VPN provider doesn’t offer it, it’s a red flag.

Why It’s Designed This Way

The VPN wasn’t invented for privacy. Originally, it’s a tool for businesses: allowing remote employees to access the internal network as if they were in the office. The encrypted tunnel between two points is the founding concept.

The “privacy” use is an adaptation. Instead of connecting an employee to their company, you connect an individual to an intermediate server to hide their traffic from their ISP. The mechanism is the same. The intention has changed.

This is important to understand because it explains the limits: a VPN does very well what it was designed for, creating a secure channel between two points. It doesn’t do the rest.

What It Changes in Practice

Before / After

Without a VPN:

Your ISP sees all the domains you visit and can profile your habits
On public Wi-Fi, your traffic is exposed to local snoopers and potential malicious activities
Sites see your real IP address and your geographical location
Your DNS requests pass in the clear (Chrome and Firefox can encrypt via DoH, but it’s not guaranteed depending on your configuration)

With a VPN:

Your ISP only sees encrypted traffic to a single server, zero visibility on your browsing
On public Wi-Fi, the encrypted tunnel makes your traffic unreadable to the local network and therefore immune to attacks or data siphoning
Sites see the IP address of the VPN server, not yours
Your DNS requests are resolved by the VPN server, not your ISP

Real-Life Use Cases

Working from public places. If you work regularly from cafés, coworking spaces, hotels, or airports, a VPN is cheap insurance. It’s the layer of protection between you and a network you don’t control.

Preventing your ISP from profiling you. You might not have anything to hide. But that’s not the point. The point is: why should your ISP be able to build a complete profile of your browsing habits, and in some cases sell it?

Keeping a stable IP address while traveling. If you work in several countries, some services behave differently, or even block you, if your IP address changes jurisdictions every couple of days. A VPN lets you appear to be in a fixed country, no matter where you are physically.

Bypassing censorship. In some countries, entire parts of the internet are blocked. A VPN lets you access them. It’s less a use case for freelancers in Europe and more about freedom of information, but it’s worth mentioning.

The Limits

This is where most affiliate sites turn a blind eye.

A VPN doesn’t make you anonymous. If you’re logged into Google, Facebook, your Apple account, they know who you are, VPN or not. The VPN hides your IP address at the network level. It doesn’t hide your identity at the application level. You log in with your credentials? The VPN doesn’t change anything. If you want real anonymity (and you know why), it’s Tor you need, and that’s another topic, with other compromises.

A VPN doesn’t protect against malware. If you download an infected file, the VPN doesn’t care. It encrypts the transport, not the content. A VPN isn’t an antivirus, not a firewall, not an anti-phishing filter (even if some providers integrate a DNS blocker, it’s a bonus, not a guarantee).

The VPN changes the intermediary. It doesn’t remove the intermediary. Without a VPN, your ISP sees your traffic. With a VPN, it’s the VPN provider that sees it. That’s why choosing the provider is critical: audited no-logs policy, open-source code, solid jurisdiction. If your VPN provider keeps logs or cooperates with intelligence agencies, you’ve just replaced one problem with another.

Free VPNs are (almost always) the problem, not the solution. If the service is free and the company isn’t a non-profit, your traffic is probably what they’re monetizing. Hola was caught selling its users’ bandwidth as a botnet, SuperVPN let millions of users’ data leak despite a “no-logs” policy. You’d be solving one problem by creating a worse one. The only notable exception: free tiers of paid providers (Proton VPN free, for example), funded by paying customers, not your data.

A VPN doesn’t bypass all geographical restrictions. Netflix, Disney+, and streaming platforms have become very effective at detecting and blocking VPN server IP addresses. It works sometimes, it doesn’t work other times, and it can change from one day to the next. If your main use is geo-blocked streaming, adjust your expectations.

In Summary

A VPN creates an encrypted tunnel between your device and a remote server. Your ISP no longer sees what you’re doing online, your real IP address is masked, and your traffic is protected from attacks on public networks. It’s not a magic armor, it’s a precise tool for specific problems, with clear limits: it doesn’t make you anonymous if you’re logged into Facebook or Instagram, it doesn’t block malware, and it shifts your trust to a provider you need to choose carefully.

In Practice: if you work from public places, travel regularly, or the idea of your ISP building a complete profile of your browsing habits bothers you, a VPN is a very reasonable investment given the protection it provides. The choice of provider (audited no-logs policy, open-source code, jurisdiction outside surveillance alliances) will make all the difference between real protection and security theater. We’ll detail exactly how to choose, criteria, comparison, recommendations, in a future dedicated article.

Read: Privacy macOS: The Settings to Change in 15 Minutes

Technical terms? Check the glossary.