The Kladde is by now a distributed system: a web application with two silos, a worker, a nightly job, a database with several schemas, an event store, queues and topics in Service Bus, plus Entra ID, Microsoft Graph and TED from the outside. In K3 you gave every identity its permissions and got every key out of the code. This module asks a level higher: Where in the system does trust flow, who checks there, and what happens when one of the parts falls into the wrong hands?
This lesson lays the foundation for the whole module. At the end, the Kladde's C4 model has a section “Trust boundaries” in which every connection says how it is checked, and a small tool reports every one where that is missing.
Three principles
Zero Trust is not a technique and not a product, but a mindset in design. Microsoft sums it up in three principles, which you find in the documentation like this: “Verify explicitly”, “Use least privilege access”, “Assume breach”.
| Principle | means for the architecture | The opposite |
|---|---|---|
| Verify explicitly | Every request proves who makes it and is checked against rules, no matter where it comes from. A token is checked for issuer, audience, signature and expiry. | “The request comes from our network, so it's fine.” |
| Use least privilege access | Every identity may do exactly what its task requires, on the smallest scope, and if possible only for as long as necessary. | One identity for all apps with Contributor on the resource group. |
| Assume breach | The design reckons with the fact that a part has already been taken over, and limits what the attacker can reach from there: separate identities, separate data, encryption, logs that make an attack visible. | A hard shell outside, a soft core inside. |
The old opposite has a name: the castle-and-moat model. A wall (the firewall, the virtual network) separates inside from outside, and whoever is inside is considered trustworthy. That never quite worked, and in the cloud it does not work at all. The Kladde has no wall behind which everything stands: Customers book from the internet, the team works on the road, the island runs in the browser, and Service Bus and Azure SQL are services with endpoints of their own. Whoever relies on “inside” has a boundary that they do not control.
Zero Trust does not replace the basics. Validating input, keeping dependencies up to date, not showing errors to the outside: All of that still applies. Zero Trust is the question you ask at every connection in the diagram: How does the other side recognize that this request is genuine?