02. Cybersecurity
Zero Trust, segmentation and SASE under real conditions
What segmenting a live network actually costs, how you cut over without downtime, and why most Zero Trust projects stall right after the audit.
Key points
- Segmenting a live network means accepting that something will break; the whole job is choosing what.
- Mapping real traffic comes before design: an official architecture diagram rarely describes what actually flows.
- Observation mode before enforcement mode is what makes the cutover reversible.
- Zero Trust does not require replacing everything: it requires knowing who reaches what, and verifying it.
Most Zero Trust projects stall after the audit
The analysis phase is comfortable, the cutover is not. The mapping is produced, the report is delivered, and nobody wants to be the person who cuts a flow on Monday morning. The project then stays at the documentary stage, with cost incurred and no risk reduced.
The blockage is not technical, it is organizational. Cutting a flow requires knowing what it serves, who will complain, and how quickly you can roll back. Without those three answers in writing, no reasonable operations manager authorizes the cutover.
That is why we treat segmentation as an operations project rather than a security project. Decisions are taken with the application teams, not against them, and every step has its rollback window.
The consequence is a longer schedule than most proposals advertise. It is also why our cutovers get completed.
Segmenting without interrupting service, in four stages
Three of those four stages are reversible. Passive discovery of real traffic, zone definition with the business teams, rules applied in observation mode, then enforcement zone by zone. At each step, a written success criterion and a rollback window that has actually been exercised.
- Passive discovery. You observe what genuinely flows, over a period covering the business cycles: month end, close, overnight backups. A rare flow is a flow you cut by mistake.
- Zone definition. Decided with the application owners, because only they know what must talk to what. A zone drawn from a network diagram produces permanent exceptions.
- Observation mode. Rules are written and evaluated but block nothing. Discrepancies surface with no consequence for users, and are corrected in calm conditions.
- Zone-by-zone enforcement. One zone at a time, with a success criterion and a rollback window that has actually been tried, not merely documented.
What Zero Trust actually requires
No user or device is granted implicit trust merely for being inside the network. In practice this means verifiable identity, explicit authorization per resource, and usable logging. It does not require replacing existing infrastructure.
The most widespread misreading treats Zero Trust as a product. No vendor sells Zero Trust: it is an architectural principle applied with the components you have, filling the gaps that remain.
The second misreading treats it as a state to reach. It is a trajectory: you progressively reduce implicit trust, starting where it costs the most: payment systems, sensitive data, administrative access.
The right opening question is therefore not “how do we become Zero Trust” but “where does implicit trust expose us most today”.
From VPN to SASE: what actually changes
A VPN pulls traffic back to the data centre before letting it out again, which penalizes cloud applications and often grants broad access to the internal network. SASE moves security closer to the user and authorizes per application rather than per tunnel. The gain is as much operational as it is security.
The difference shows on two points. Hybrid work performance first: a user reaching a cloud application has no reason to transit through head office. Then the access perimeter: a VPN tunnel generally opens far more than the user needs.
SASE is not a universal answer for all that. It presumes mature identity management, because authorization shifts onto identity. An organization whose accounts are poorly kept will relocate its problem rather than solve it.
We check that point before recommending the architecture, and it sometimes leads to treating identity management first.
What we see in the field
What mapping always reveals
Mapping real traffic almost always produces three surprises, and they are the same from one organization to the next.
The first is the forgotten flow: an application talking to a server nobody administers any more, usually inherited from a project closed years ago. The second is a vendor’s access (standing and broader than necessary)whose existence appears on no diagram.
The third concerns administrative workstations. They are regularly used for day-to-day office work (email, browsing)which cancels most of the benefit of any segmentation.
These observations come from our engagements and are offered as observed patterns, not as a measurement.
Frequently asked questions
Do we have to replace our infrastructure to segment?
Rarely in full. Segmentation builds first on what exists: switches, firewalls, access controllers, directory. The work consists of using their real capabilities, often underexploited, and identifying the few points where a component is genuinely missing. We establish that gap before recommending any purchase, and since we resell no licences, that conclusion earns us nothing.
How long does a segmentation project take?
It depends on the number of zones, the quality of existing documentation and the availability of application teams: we do not announce it in advance. What is constant is the sequencing: discovery must cover a full business cycle, and each zone cutover is followed by an observation period before the next.
How do you demonstrate compliance after segmentation?
Through the traceability of inter-zone access, which becomes usable once zones are defined. This is in fact one of the least anticipated benefits of the work: a flat network demonstrates very little, whereas a segmented network naturally produces the evidence auditors and regulators ask for.
Can you segment a live industrial environment?
Yes, but the sequence differs: you start with an inventory of connected assets, because industrial environments almost always contain equipment unknown to the IT department. Observation mode runs longer, and some cutovers are scheduled during planned shutdown windows. Reversibility matters even more there than elsewhere.
Do you work with our teams or instead of them?
With them, by default. Segmentation produces rules somebody will maintain for years: if your teams did not take part in the trade-offs, they will inherit a setup they dare not modify. Knowledge transfer is part of the work, not an option at the end of the project.
Find out whether your network can be segmented today
A first conversation assesses the state of your documentation, the maturity of your identity management, and which zone it would be sensible to start with.
Sources
- NIST SP 800-207, Zero Trust Architecture · the reference definition of the model
- Canadian Centre for Cyber Security · guidance on segmentation and access control
- CIS Critical Security Controls · reference controls, including asset inventory
Go further
Network & connectivity
The architecture any segmentation rests on.
Case studies
Documented engagements, with their real constraints.
IT security foundations
The same principles, scaled to a smaller business.
Is your infrastructure ready for the next threat?
A discovery call, without commitment, to understand your reality before recommending anything.