Zero Trust does not mean absolute distrust. It means replacing implicit trust assumptions with explicitly modeled trust relationships. Instead of trusting the internal network across the board, every trust relationship is defined deliberately, for example trust in a token from an identity provider. Large organizations typically structure Zero Trust in six areas: network, identities, devices, data, applications and monitoring.
Key Takeaways
- Zero Trust does not mean “trust no one”. It means replacing implicit trust with explicitly modeled trust relationships: who trusts whom, why and on what basis?
- Before tokens and authorization rules can scale, the identity providers have to be consolidated. Telekom cut the number of identity providers from 30 to 3.
- Zero Trust in a large organization needs a shared definition. Without one, ten people in a room will produce eleven different opinions about the same concept.
- The place to start is where an external request crosses your own trust boundary: what has to be available at that point, and whom do you have to trust to make a sound authorization decision?
- Security initiatives make progress in established organizations when they attach to ongoing business goals. Cost-saving programs offer a win-win, because Zero Trust measures deliver directly measurable effects there.
Zero Trust Is a Buzzword Every Role Reads Differently
Any Zero Trust implementation starts with a problem: there is no shared definition. Walk into a meeting with ten colleagues, ask what Zero Trust means, and you walk out with eleven opinions. That is exactly where every serious project on the topic has to begin.
The term stands for a trend that forces companies to rethink their security concept. But each role reads it from its own corner. A network engineer sees an insecure intranet and asks for new hardware. System architects wave it off because they consider their system secure already.
Waldemar Schäfer of Deutsche Telekom warns against repeating an old mistake. With SOA, companies were sold an ESB with the promise that they now had a decoupled architecture. The term carried the expectation, and the technology didn’t deliver it. To keep that from happening with Zero Trust, a company first has to define what it means by the term.
What Zero Trust Really Means: Explicit Trust
The “zero” in Zero Trust isn’t meant literally. The motto “Always verify, never trust” contradicts itself: to verify something, you have to trust the data you check it against.
What really matters is the difference between implicit and explicit trust. Zero Trust forbids implicit trust. Every trust relationship is modeled explicitly instead.
An example: an API trusts the token of an identity provider. That is a deliberately modeled relationship, not a silent assumption along the lines of “the intranet is secure anyway”. The question is always the same: which parts of the infrastructure do you trust strategically, and which don’t you?
For architects, this adds a new view. Until now, they modeled data flows, the logical view and the process view. Zero Trust adds another dimension: whom do you trust at which point, and why?
The Six Aspects Telekom Uses to Structure Zero Trust
Deutsche Telekom has broken Zero Trust down into six areas: network, identities (IAM), devices, data, applications and monitoring. These six aspects form the common framework that the different teams work within.
The trigger was a clash of perspectives. Waldemar was responsible for API authorization, while an existing Zero Trust initiative dealt mainly with identity providers, some networking and devices. Both used the same word and meant different things.
The fix was to sit down and define the areas together. A shared definition is the precondition for selling the concept in a large organization at all. No business unit is standing by, waiting eagerly for new security features.
Clean Up Before You Secure: Consolidate Identity Providers First
Before APIs start checking identity tokens, the number of token sources has to come down. Otherwise you create exactly the chaos at the token level that you are trying to prevent at the API level.
For employees alone, Telekom found around 30 identity providers, plus more for B2B and B2C. If APIs started trusting all of these sources, the complexity would multiply. So the first step was consolidation: from 30 to 3 strategic identity providers.
These three had to support modern protocols, so that teams would want to use them voluntarily. Support came from management and from an ongoing audit. When the pressure from outside is already there, a clean-up campaign is easier to push through.
Zero Trust Implementation at Telekom: Build Enablers, Connect Consumers
The rollout is iterative, not a big bang. Enablers are provided first, then consumers are connected step by step. A big bang doesn’t work in a large organization.
A second driver was the decision to let devices go online. That raised the question of what it means for the applications. There are several landing zones with different levels of protection, and the infrastructure has to secure the applications well enough to expose them to the internet. That is not trivial: the question isn’t whether you’ll be attacked, but when and how hard.
The next steps are happening at the API gateway. Tokens are to be standardized there, and a dedicated team manages the authorization policies centrally. The first proofs of concept are done, and further milestones follow release by release.
How far you standardize is a question of level. The higher up you standardize, the longer it takes and the more effort it costs. The further down, the faster and more pragmatic. In the end, a requirement lands as a story, but on different levels: first at system or hub level, then with the teams.
| Standardization Level | Characteristics |
|---|---|
| High up (organization-wide) | slower, more effort, but broadly valid |
| Far down (close to the team) | faster, more pragmatic, but local |
If a security requirement lands on the teams with no lead time because a security officer wants it by tomorrow, chaos follows. That’s why every requirement starts with the system and hub architects before it is handed down to the teams.
Security Loses to Features Without a Change in Mindset
The biggest hurdle is the attitude of the teams, much more than the technology. You join a team, explain Zero Trust and hear: nice, but we’re already secure.
The change in mindset starts with questions, not statements. Whom do you actually trust? A, B, C, D. Once that’s on the whiteboard, the next question follows: have you checked what security level these parties have and how well they are protected? If the answer is no, your own security level is only as high as that of the weakest party you trust.
This shift rarely sticks. At the conference, it all sounds convincing, and back at work the feature pressure returns. You know you should do security, but you think you’re doing pretty well. This is exactly where the concept succeeds or fails.
“You listen to something and think it’s good. But when you get back, the pressure comes with the features. Security is always fighting against features.”
(Waldemar Schäfer)
If you want to win teams over, authority won’t do it. The classic “The chief architect says you must” rarely works. What does work: asking questions, using the pressure from data protection and information security, and offering concrete help. Look, this is the enabler, and this is how I connect you. Help beats orders.
Where to Start: Protect the Crown Jewels and Find Win-Win Initiatives
Two criteria decide where to start. The first is the data. Protect the crown jewels, meaning the data that needs the most protection, and look there first.
The second is a business initiative that creates a win-win. Pushing a security initiative on its own is hard. Tie it to a project that already has momentum, and it gets easier.
At Telekom, that was a cost-cutting initiative. When an application consumes data with a higher protection class, the requirements go up: no operation in the public cloud, operation from Germany, higher costs. That raises the question of whether the application really needs that data. If the data can be removed, the protection class drops and so do the costs. Where cost savings are in reach, you step in and make the protection tangible instead of just promising it.
The First Practical Step: Sit on the API and Ask Whom You Trust
If you want to get going, start at your own trust boundary. Imagine sitting on the API and ask: what do I need to be able to authorize?
In detail, that means: what data do I need, in what quality, how fast, and how do I get it? Latency and performance come later. The starting point is realizing that the API is the first place where a foreign, potentially malicious request comes in. That is where trust ends. What do I need to have ready there, and whom do I trust to go further?
There is one step before that, though, and it’s the real sticking point: recognizing that Zero Trust is a buzzword that has to be defined. For some people it’s obvious that you have to do it, others understand something completely different by it. You have to take that common understanding all the way back to the start and define it together from scratch.
Not Every Area Can Be Secured Equally Well
Structured domains are the easy part. APIs with a clear structure can be authorized well with policies, and the model works cleanly there.
Unstructured data lakes are harder. If all data is thrown into a lake to create business value, there is no structure that reliable authorization could build on. There is no ready answer for this case yet.
This follows from the approach rather than contradicting it. Not all concepts are equally mature. The first step is to have a strategy and an enabler, and then roll the enabler out broadly in parallel. The current challenge lies exactly in this phase, getting from proof of concept to broad adoption.
Frequently Asked Questions
Why does the guiding principle “Always verify, never trust” reach its limits?
It contradicts itself: Anyone who verifies something must trust the data they’re checking against. The “zero” in Zero Trust isn’t meant literally. What’s prohibited is implicit trust, such as assuming the intranet is already secure. Instead, every relationship is deliberately modeled, for example an API that trusts the token from a specific identity provider.
Why do teams in Zero Trust projects often talk past one another?
Because there’s no shared definition. If you go into a meeting with ten colleagues, you’ll come out with eleven opinions. The network engineer sees an insecure intranet and calls for hardware, while system architects have long considered their system to be secure. Waldemar Schäfer points to SOA, where an ESB was marketed as a decoupled architecture but the technology failed to deliver on the promise of the term.
How does Zero Trust change the work of architects?
It adds a new perspective. Until now, data flows, logical views, and process views were modeled. Zero Trust adds the question of whom to trust at which point and why. Large organizations often break this down into six areas: network, identities, devices, data, applications, and monitoring. These areas form the framework within which different teams work together.
Why should identity providers be consolidated before APIs verify tokens?
Otherwise, the very chaos one is trying to prevent at the API level will arise at the token level. Telekom found around 30 identity providers for employees alone, not to mention B2B and B2C providers. If APIs were to trust all these sources, the complexity would multiply. The company consolidated to three strategic providers that had to support modern protocols so that teams would use them voluntarily.
At what level should a security requirement be standardized?
It’s a matter of balancing priorities. The higher up the standardization takes place, the longer it takes and the more resource-intensive it is, but the result applies broadly. Further down, closer to the teams, the process is faster and more pragmatic, but remains localized. If a requirement lands directly with the teams without any lead time, because a security officer demands it starting tomorrow, chaos ensues.
How do you win over development teams that already consider themselves secure?
With questions instead of statements. Who do you trust? And have you checked what security level these entities have? If the answer is no, your own security level is only as high as that of the weakest entity you trust. Authority doesn’t help much: The typical “The Chief Architect says you have to” rarely works. Concrete enablers and support are more effective.
Where is it most worthwhile to start with Zero Trust?
With the “crown jewels” (that is, the data most in need of protection) and with a business initiative that’s already gaining momentum. At Telekom, this was a cost-reduction program: If an application processes data in a higher protection class, it cannot run in the public cloud and must be operated from Germany. If that data can be removed, both the protection class and costs decrease.
Can every data area be secured equally well with Zero Trust?
No. Structured domains are the easy part: APIs with a clear structure can be neatly authorized using policies. With unstructured data lakes, the structure needed for reliability in authorization is missing, and there is no ready-made solution for this. The concepts are at different stages of maturity: first strategy and enablers, then expanding in parallel.
