← Back to whitepapers

White paper · January 2026

White paper — Zero Trust: securing the distributed enterprise

Zero Trust: securing the distributed enterprise. 44 pages to move from implicit trust to continuous verification — written as practitioners: we design and operate systems for SMEs and mid-caps, and we often arrive after the incident.

  • The three principles and their contractual requirement: verify explicitly, least privilege, assume breach
  • Identity first: phishing-resistant multi-factor authentication, the birth and death of an account, service accounts and contractors
  • The five ordered worksites, each with its exit threshold
  • The six ways to fail: the repainted VPN, patchy multi-factor authentication, the ghost account, the eternal exception
Cover of the white paper
White paper · January 2026
White paper — Zero Trust: securing the distributed enterprise

Read the opening pages

The 44 pages of this white paper. The first 13 are readable in full; the rest is sent by email.

Page 1 of the white paper “Zero Trust: Securing the Distributed Enterprise”
Page 1

White paper · January 2026

Zero Trust: securing the distributed enterprise

From implicit trust to continuous verification

"We no longer ask where a connection comes from — we ask who carries it, on which device, toward which data, and what happens if it lies. This whole book fits inside that shift of question."

5 worksites

1 intrusion

1 quarter

Identities, devices, access, compartments, detection — ordered, with their exit thresholds

Dissected link by link, with the control that cuts each one

The first 90 days' roadmap, from the access inventory to the first locked-down perimeter

For executives, CIOs and CISOs of SMBs and mid-market firms — with an access doctrine to copy, a vendor-requirements grid, a jargon-free glossary and a twenty-question self-assessment.

Page 2 of the white paper “Zero Trust: Securing the Distributed Enterprise”
Page 2

Zero Trust

Contents

Foreword 03 The shift — seven reversed reflexes 04 Where to start, by role 06 1 The perimeter has dissolved Where your access went · Anatomy of a modern intrusion · The bill for implicit trust · Three starting points 07 2 Three principles, zero dogma Verify explicitly · Least privilege · Assume breach · From each principle to its contractual requirement 11 3 Identity first Phishing-resistant MFA everywhere · Birth, life and death of an account · Privileges, service accounts and third parties 15 4 Devices, networks, data: shrinking the blast radius The healthy device as an entry condition · Compartmenting what hurts · SaaS and travelling data 19

5 The deployment path Five ordered worksites — inventory, lock down identities, condition access, compartment and detect, keep it alive — each with its exit threshold 23 6 Six ways to fail The repainted VPN · MFA with holes · The ghost account · The eternal exception · The alert nobody reads · The user who works around 28 7 What is imposed on you — NIS2, insurance, offensive AI The regulatory calendar · What the insurer already demands · Phishing in the deepfake era 32 8 The first quarter Three tests to locate the start · The D1-D90 timeline · Five numbers to steer by · The roadmap to pin up 36 Moving to execution 40 Appendices — Vendor grid, self-assessment, glossary 41

The stance

You do not "switch" to Zero Trust the way you change firewalls. You remove implicit trust access by access, starting with those that can kill the business — and every removal is verifiable: one account fewer, one privilege fewer, one minute of detection gained.

Page 3 of the white paper “Zero Trust: Securing the Distributed Enterprise”
Page 3

Foreword Zero Trust

Foreword

The password fell on a Friday evening — a supplier email imitated, a contractor in a hurry, a "technical" account multi-factor authentication had never reached. Over one weekend the connection crossed the VPN, wandered from server to server on a network where everyone sees everyone, and found the backups. That company had a recent firewall, an up-to-date antivirus, a reassuring audit. None of it weighed anything, because everything rested on an assumption nothing justified anymore: inside, we're among ourselves. There is no inside anymore.

The term "Zero Trust" is fifteen years old, and it has been battered by everyone who put it on a brochure. Stripped of the marketing, it names something simple and demanding: no access is granted because it comes "from inside" — each one is verified explicitly, limited to what it needs, and observed while it is exercised. It is not a product, not a network architecture, not a project you finish: it is a discipline deployed worksite by worksite, and every advance can be counted — in protected accounts, in privileges removed, in minutes of detection gained.

We write as practitioners: we design, deploy and operate systems for SMBs and mid-market firms, and we often arrive after the incident. What we see there looks nothing like the brochures: security programs rarely fail on technology — they fail on a forgotten contractor account, a "temporary" exception that just turned two, a user who built a shortcut because the official path slowed them down. This document dwells precisely there.

How to use it. Each chapter stands alone; page 6 orients you by role. In a hurry? The shift (p. 4-5), the deployment path (ch. 5) and the first quarter (ch. 8) form a coherent whole in ten pages. And if you do only one thing after reading: the access inventory of worksite 1 — it takes two weeks and changes the conversation.

Enjoy the read — and may you never live the Monday morning of the first page.

Cédric Guittard

Anna Hoang

cedric.guittard@clarendis.com

anna.hoang@clarendis.com

for the Clarendis team — January 2026

Page 4 of the white paper “Zero Trust: Securing the Distributed Enterprise”
Page 4

The shift Zero Trust

The shift, in seven reversals

Zero Trust does not add a layer: it reverses reflexes twenty years in the making. Seven reversals sum up the program — on the left the inherited reflex, on the right what replaces it, and where this book equips it.

We leave behind

We install

"The connection comes from the internal network, so it is legitimate."

Every access proves who it is — strong identity, known device, coherent context — wherever it comes from. (ch. 2, 3)

We leave behind

We install

"The VPN protects remote work."

Application access, not network access: you open one application to one identity — never the whole network to a tunnel. (ch. 4)

We leave behind

We install

"Rights accumulate with seniority — nothing ever gets removed."

Least privilege with an expiry date: every right has an owner, a justification and a review — the dormant right falls on its own. (ch. 3)

We leave behind

We install

"The incident is a hypothesis — we invest to prevent it."

The breach as a working assumption: every perimeter is designed by asking what happens when — not if — a link gives way. (ch. 2, 4)

Page 5 of the white paper “Zero Trust: Securing the Distributed Enterprise”
Page 5

The shift Zero Trust

We leave behind

We install

"Security is IT's business — the business units endure it."

Controls designed with their user journey: SSO before MFA, friction reserved for the sensitive — security that annoys ends up bypassed, therefore blind. (ch. 6)

We leave behind

We install

"Security is proven by the annual audit."

Five numbers read every month: MFA coverage, dormant accounts, revocation delay, share of conditioned access, time to detect. (ch. 8)

We leave behind

We install

"Zero Trust is a big project: budget, consultancy, two years."

Five ordered worksites, the first in 90 days: most of the risk falls with identities and access — often with licences already paid for. (ch. 5, 8)

What we will not tell you

That Zero Trust can be bought (no product contains it), that it can be finished (it is a regimen, not a cure), or that everything must be rebuilt (most mid-market firms already own, in their current licences, half the building blocks of worksite 2). This book compares no vendors: it arms you to ask them the right questions — the grid on page 41 is made to be laid on the table.

The question that orders the whole program:if this identity were compromised tonight, what would the attacker see, how far would they get, and how soon would we know? Asked of every account, every application, every contractor, it advantageously replaces most architecture committees.

Page 6 of the white paper “Zero Trust: Securing the Distributed Enterprise”
Page 6

Where to start Zero Trust

Where to start, by role

Nobody reads a white paper cover to cover on a Tuesday. Here is the shortest path to what concerns you — and the action that can follow this very week.

Executive team

The shift (p. 4-5) → ch. 1 → ch. 7 → ch. 8. You will find what implicit trust costs, what NIS2 and your insurer already demand, and the three decisions only you can make.

40 minutes

This week: ask for the company's MFA coverage rate — executives and contractors included. The answer (or its absence) locates everything else.

CIO

Ch. 3 → ch. 4 → ch. 5. The order of the worksites is the heart of your budget arbitration: identities before network, conditional access before micro-segmentation — and what can be done with licences you already pay for.

Full read useful; ch. 3-5 first

This week: list the applications reachable without going through your SSO. That is your map of blind spots.

CISO / security lead

Ch. 5 → ch. 6 → appendices. The worksites' exit thresholds are your program milestones; the six ways to fail, your monthly review; the vendor grid, your next procurement.

Your working tools: ch. 5, 6 and appendices

This week: count the active security exceptions and their median age. Past 90 days, an exception is a rule that will not say its name.

You are just out of an incident

Anatomy of an intrusion (p. 8) → worksites 1-2 (p. 24-25) → self-assessment (p. 42). You will know which link gave way at your place, what would have cut it, and in what order to rebuild — without yielding to the big-purchase reflex under pressure.

The emergency path

Page 7 of the white paper “Zero Trust: Securing the Distributed Enterprise”
Page 7

Chapter 1

The perimeter has dissolved

1

Where your access really lives today, how a modern intrusion unfolds link by link, what implicit trust costs when it breaks — and three starting points depending on your organization.

1.1 Where your access went

Do the exercise on a sheet of paper: on one side, what lived behind your firewall ten years ago — email, ERP, files, payroll. On the other, where each lives today. Email is with a hyperscaler, CRM and payroll in SaaS, the ERP reachable by sales reps from their phones, accounting open to the external accountant, the CMMS to the maintenance contractor, EDI to suppliers. Add two days a week of remote work and laptops sleeping on trains: the majority of your daily connections never cross your walls anymore. The firewall now protects a server room — not the company.

This displacement was never decided: it settled, usage after usage, without the security model ever coming back to the table. We kept the castle-and-moat architecture — a safe inside, a hostile outside, a drawbridge — while emptying the castle of its inhabitants. Attackers understood it before defenders did: why force a rampart when you can borrow a badge? Phishing, password reuse and session theft are not technical attacks; they are attacks on implicit trust.

The founding reversal. The one defensible perimeter left is the meeting point between an identity, a device and a resource. That is where Zero Trust places all its controls: not where the connection passes, but who carries it, on what, toward what, and in what state.

Page 8 of the white paper “Zero Trust: Securing the Distributed Enterprise”
Page 8

1

Chapter 1 — The perimeter has dissolved Zero Trust

1.2 Anatomy of a modern intrusion — and the control that cuts each link

The intrusion in the foreword is nothing exotic: it is the most documented scenario in incident reports, the one we find in the vast majority of response cases. Reading it link by link shows something product org-charts hide: every step has a control that cuts it, and none of those controls is a firewall.

#

The attack link

What happens

What would have cut it

1

The phishing

An email imitates a supplier; the contractor types their password into a fake page

Phishing-resistant MFA: the stolen password no longer suffices (ch. 3)

2

The illegitimate login

A connection at 11 pm from an unusual country, on an unknown machine — accepted without a question

Conditional access: abnormal context = stepped-up verification or refusal (ch. 4)

3

Entry through the VPN

The tunnel opens the whole network, not one application: the attacker sees everything the contractor sees — and more

Application access: an identity reaches only its named applications (ch. 4)

4

Lateral movement

From server to server on a flat network, reusing admin credentials found along the way

Compartments + separate, ephemeral admin accounts (ch. 3, 4)

5

The silent escalation

Three days of noiseless exploration: nobody reads the logs, no alert is wired to abnormal logins

Identity monitoring: the access anomaly fires, someone answers (ch. 5)

6

The final encryption

The backups, reachable from the office network, are encrypted first — then production

Isolated, immutable backups, tested in restoration (ch. 4)

Read the right-hand column as a budget. Six controls, four of which belong to identity and access — not to the network. That is this document's entire battle order: chapters 3 to 5 climb that column, from the most profitable to the most structuring. And notice what is missing from it: none of these six controls is called "buy a new firewall".

Page 9 of the white paper “Zero Trust: Securing the Distributed Enterprise”
Page 9

1

Chapter 1 — The perimeter has dissolved Zero Trust

1.3 The bill for implicit trust

Implicit trust costs nothing as long as it holds — that is its budgetary perversity: free until the day it is ruinous. To arbitrate between "we carry on as is" and a Zero Trust program, you must therefore price the event, not the subscription. The reconstruction below follows a typical 200-person industrial mid-market firm hit by the page 8 scenario — each line can be recomputed at your place in one meeting with the CFO:

The cost of a successful encryption — typical industrial firm, 200 people

Production halt & delayed order book (12 days)

€620k

Rebuilding the IT estate & incident response

€280k

Insurance surcharge & lost customers (3 years)

€210k

Reconstruction of a typical case from incident-response files — excluding the ransom, which we advise neither paying nor budgeting. Your figures will differ; the order of magnitude, rarely.

Against that column, the worksite that cuts links 1 to 4 — MFA everywhere, account lifecycle, application access — is measured in tens of thousands of euros and in quarters, not in millions or years. Zero Trust is not one more line in the security budget: it is the replacement of an uninsurable risk by an amortizable program. Increasingly, it is also the condition for obtaining the insurance policy itself (ch. 7).

The argument for the board: present the three bars above recomputed with your numbers, next to the cost of worksite 2 (often largely covered by licences already paid). The decision makes itself — all that remains is to date it.

Page 10 of the white paper “Zero Trust: Securing the Distributed Enterprise”
Page 10

1

Chapter 1 — The perimeter has dissolved Zero Trust

1.4 Three starting points — recognize yours

The principles do not vary; the first move does. Three situations cover most of what we encounter:

The SMB with no security lead

10-80 people

IT is carried by a provider or a versatile employee; security, by nobody. Everything is in SaaS or nearly — and that is a decisive advantage: no network debt to undo, Zero Trust building blocks already included in existing subscriptions.

Your first move: turn on MFA on email and the office suite — this very week — then run worksite 1 with your provider, contracted on this document's thresholds.

The mid-market firm with a legacy network

80-1,000 people

A real IT estate, an old directory that has sedimented fifteen years of accounts and rights, a generous VPN, business applications that never heard of SSO — and often an industrial site where OT complicates everything. The core audience of this document.

Your first move: the access inventory (worksite 1) — you will find more accounts than employees, and that is exactly the number that triggers the program.

The multi-entity group

1,000+ people, subsidiaries, acquisitions

Several directories, maturity levels inherited from acquisitions, network interconnections woven deal after deal. The dominant risk: the least protected subsidiary becomes the doorway to all the others.

Your first move: treat every inter-entity interconnection as external access — verified, limited, observed — and impose the worksite 2 baseline as a group standard, including on new acquisitions from closing day.

What all three share: the first move costs almost nothing and requires no purchase. Zero Trust always begins by seeing your access clearly — never with a tender.

Page 11 of the white paper “Zero Trust: Securing the Distributed Enterprise”
Page 11

Chapter 2

Three principles, zero dogma

2

Verify explicitly, grant least privilege, assume breach: three sentences easy to recite, hard to keep. This chapter translates them into verifiable requirements — the kind you write into a contract, a specification or a quarterly review.

2.1 Verify explicitly — the end of the benefit of the doubt

The first principle forbids one precise thing: granting access on the strength of an inherited signal — the internal IP address, the established VPN tunnel, the session open since Tuesday. Instead, every access request presents its proofs at the moment it happens: a strong identity (MFA happened, recently, with a phishing-resistant factor), an identified, healthy device (known to the company, encrypted, up to date), a plausible context (time, place and behaviour do not clash with history). Three proofs, re-evaluated continuously — not once at the door.

The classic objection — "we are not going to re-authenticate people every ten minutes" — confuses verification with friction. Continuous verification is silent: the signals re-evaluate in the background, and the user is prompted only when something changes — a new device, a sensitive action, unusual behaviour. Well tuned, Zero Trust bothers the legitimate user less than the old world did: SSO replaced fifteen passwords, and the trusted session lasts as long as nothing moves.

The requirement that follows — to write verbatim into your specifications: "Every user-facing application goes through the central directory and the SSO; every authentication requires a phishing-resistant second factor; no IP allowlist counts as authentication." A vendor who cannot sign that sentence is not compatible with your program.

Page 12 of the white paper “Zero Trust: Securing the Distributed Enterprise”
Page 12

2

Chapter 2 — Three principles, zero dogma Zero Trust

2.2 Least privilege — access as a loan, never a gift

In most organizations, rights are granted on arrival, added at every job change and never removed: after ten years, the management controller turned sales director still opens payroll files. It is nobody's fault — it is the natural slope of any system where granting is a gesture and removing is a project. Least privilege reverses the slope: every right is born with a justification, an owner and a deadline, and it is its renewal that requires a gesture — not its removal.

In practice, three mechanisms keep the principle without breeding bureaucracy: roles rather than individual rights (you join "accounts payable", you do not accumulate forty personal authorizations), the six-monthly review by the business manager (thirty minutes: each team member, each role, keep or remove), and on-demand elevation for administration (admin rights are borrowed for a task and a duration, then fall back — nobody is an administrator "permanently").

The gain is not theoretical. Go back to link 4 on page 8: lateral movement lives off accumulated rights — every dormant privilege is one more corridor for the attacker. Reducing rights literally shrinks the building he can visit. It is also the cheapest control in the program: removing a right costs nothing.

The requirement that follows:"Every access right has a named business owner and a review date; any right not confirmed at its review falls automatically; administration rights are obtained on demand, for a bounded duration, and every elevation is logged."

Page 13 of the white paper “Zero Trust: Securing the Distributed Enterprise”
Page 13

2

Chapter 2 — Three principles, zero dogma Zero Trust

2.3 Assume breach — design for the day it breaks

The third principle is the most counter-intuitive for a board: you no longer design the system to prevent intrusion, you design it also for the day intrusion has succeeded. Not out of fatalism, but arithmetic: one click out of thousands is enough for link 1 to give way — the assumption "nobody will ever get fooled" loses every time. The design question becomes: when an identity or a device falls, what does the attacker see, how far do they get, how soon do we know?

Three practical consequences. The blast radius is measured: for every workstation and account, you must be able to say what is reachable from it — if the answer is "pretty much everything", worksite 4 is the priority. Detection is a first-rank control, not a luxury: a log nobody reads does not exist; an alert without a named owner, neither. Restoration is rehearsed: isolated, immutable backups, and one real restoration exercise per year — not a provider's attestation.

This principle has an underrated political virtue: it makes security debatable in a boardroom. "Are we protected?" has no honest answer; "how long to detect an abnormal login on payroll?" has one — numeric, improvable. Assuming breach replaces an unverifiable promise with questions that can be measured.

The requirement that follows:"Backups are unreachable from the office network and tested in restoration at least once a year; any abnormal login on a sensitive system triggers an alert carried by a named owner; the blast radius of critical perimeters is documented and reviewed."

Why three principles and not ten: everything else — SSO, conditional access, segmentation, PAM, monitoring — is merely the tooling of these three sentences. When a vendor shows you a product, ask which of the three principles it serves, and how that will be measured at your place. Silence is an answer.

The remaining 31 pages are in the complete document.

Download the white paper
Page 14, blurred — available in the full document
Page 14 · in the full document
Page 15, blurred — available in the full document
Page 15 · in the full document
Page 16, blurred — available in the full document
Page 16 · in the full document
Page 17, blurred — available in the full document
Page 17 · in the full document
Page 18, blurred — available in the full document
Page 18 · in the full document
Page 19, blurred — available in the full document
Page 19 · in the full document
Page 20, blurred — available in the full document
Page 20 · in the full document
Page 21, blurred — available in the full document
Page 21 · in the full document
Page 22, blurred — available in the full document
Page 22 · in the full document
Page 23, blurred — available in the full document
Page 23 · in the full document
Page 24, blurred — available in the full document
Page 24 · in the full document
Page 25, blurred — available in the full document
Page 25 · in the full document
Page 26, blurred — available in the full document
Page 26 · in the full document
Page 27, blurred — available in the full document
Page 27 · in the full document
Page 28, blurred — available in the full document
Page 28 · in the full document
Page 29, blurred — available in the full document
Page 29 · in the full document
Page 30, blurred — available in the full document
Page 30 · in the full document
Page 31, blurred — available in the full document
Page 31 · in the full document
Page 32, blurred — available in the full document
Page 32 · in the full document
Page 33, blurred — available in the full document
Page 33 · in the full document
Page 34, blurred — available in the full document
Page 34 · in the full document
Page 35, blurred — available in the full document
Page 35 · in the full document
Page 36, blurred — available in the full document
Page 36 · in the full document
Page 37, blurred — available in the full document
Page 37 · in the full document
Page 38, blurred — available in the full document
Page 38 · in the full document
Page 39, blurred — available in the full document
Page 39 · in the full document
Page 40, blurred — available in the full document
Page 40 · in the full document
Page 41, blurred — available in the full document
Page 41 · in the full document
Page 42, blurred — available in the full document
Page 42 · in the full document
Page 43, blurred — available in the full document
Page 43 · in the full document
Page 44, blurred — available in the full document
Page 44 · in the full document
Share this white paper