← All coursesBack to the simulator →

Zero Trust and microsegmentation

Why a wall at the network border is not enough and what to do instead: the attacker pivot and lateral movement, the three Zero Trust principles, least privilege in rules (any-any, default deny, shadowed rules), role-based microsegmentation, identity verification with 802.1X and RADIUS, blast radius and decoys, and the journey from a flat network step by step.

This is a text preview of the lessons for reading. The full version – an interactive simulator with animations, exercises and quizzes – runs in the app.

▶ Launch the interactive version

Lesson 1: Why the perimeter is not enough

Castle and moat: the model that failed

NETFWSWSRVHRIOTGUESTthe wall at the border: outside unsafe, inside safe

Before you start: this course builds on basics from the beginner courses (addresses and mask, gateway, VLANs, ports, DNS, firewall) – if any feels unfamiliar, check those first. The classic network security design is nicknamed castle and moat: you build a solid wall at the border (a firewall at the crossing into the internet), and everything inside is treated as trusted. The outer world is dangerous, the internal network is safe. The model has one huge advantage – it is simple – and one fatal weakness: nobody checks anything inside. Whoever gets past the wall moves around the network as if at home. And getting past the wall is fairly easy today: one employee clicking an attachment in a phishing email, one forgotten printer with old firmware, one contractor laptop, one service exposed to the internet. The wall also assumes a clear boundary exists – and it no longer does: people work from home over VPN, data sits in the cloud, phones and IoT devices join the network. The perimeter fell apart into dozens of small entrances. This course is about what to do instead: stop trusting a location in the network and start verifying at every access who the requester is and whether they are entitled. That is called Zero Trust. It is not a product you buy and install – it is a way of designing, which we will assemble piece by piece in this scene.

Step by step

  1. The castle and moat model: a firewall at the border separates the dangerous internet from the ‘safe’ internal network.
  2. Inside, everything trusts everything: the computer, the server, the printer and the guest laptop. Nobody checks anything there.
  3. But the wall is easy to cross today: a phishing email, an old printer, a contractor laptop. One entrance is enough.
  4. And the boundary is no longer clear either: work from home, cloud, phones, IoT. The perimeter fell apart into dozens of small entrances.

Pivot: the attacker is already inside

NETFWSWSRVHRIOTGUESTthe attacker takes the DMZ server exposed to the internet

Let us look at what an attacker actually does once inside – you need this scenario in your head, because it is the justification for the whole course. An attacker usually does not start on the most valuable machine. They start where they got in most easily: an employee computer, a camera system, a server in the DMZ (a separate band for services exposed to the internet). From there they pivot: they use the captured machine as a springboard and look around at who that machine can talk to. In a flat network with no internal boundaries the answer is devastating – everything. Then comes lateral movement: the attacker hops from machine to machine, harvests credentials, hunts for weakly protected services and advances toward what they really came for – the database, the backups, the accounting. Notice that this progress has nothing to do with the wall. The border firewall sees only traffic between the inside and the internet; traffic between two machines inside never passes before its eyes at all. That is exactly why Zero Trust starts with a question the classic design never asks: ‘and what if the attacker is already inside?’ You will see it step by step in the scene – from a captured DMZ server to data it should never have been able to reach.

Step by step

  1. The attacker starts where it is easiest – say on the DMZ server that is exposed to the internet.
  2. Then the pivot: the captured machine serves as a springboard. Who may it talk to? In a flat network, everything.
  3. Lateral movement: the attacker hops machine to machine harvesting credentials – the border firewall never sees this traffic.
  4. The wall still stands and reports ‘all clear’. So Zero Trust asks: and what if the attacker is already inside?

The three Zero Trust principles

NETFWSWSRVHRIOTGUESTprinciple 1: verify explicitly, not by location

Zero Trust rests on three principles, and they are worth knowing verbatim – the rest of the course is just their translation into concrete settings. 1) Verify explicitly. Never assume trust from where someone comes from. A device being in an office socket or on the corporate Wi-Fi is no proof it belongs there. Every access should rest on a verified identity (who it is) and on the state of the device – not on a cable. 2) Least privilege. Every account, device and service gets exactly as much access as it needs to work – and nothing more. Not ‘everyone everywhere’, but ‘accounting to the accounting server, the printer nowhere’. This includes privileges not being forever: what stopped being used gets taken away. 3) Assume breach. Design the network as though the attacker were already inside. Ask not ‘how to keep them out’, but ‘where do they get from here once they are in’. Microsegmentation, monitoring and fast detection follow from that. Notice how the three hold together: the first decides who may, the second where they may, the third says what happens when it goes wrong anyway. And none of them is bought – all are designed and configured. Soberly put: Zero Trust is the discipline of asking at every connection ‘why is this actually allowed?’.

Step by step

  1. Verify explicitly: a device sitting in an office socket is no proof it belongs. A verified identity decides.
  2. Least privilege: accounting to the accounting server yes, the printer nowhere. Exactly the access the work needs.
  3. Assume breach: ask not ‘how to keep them out’, but ‘where do they get from here once they are in’.
  4. The three hold together: the first is who may, the second where they may, the third what happens when it fails anyway.

▶ Open in the simulator

Lesson 2: Least privilege in rules

From any-any to the specific

NETFWSWSRVHRIOTGUESTany-any: from anywhere to anywhere, any port

The least-privilege principle sounds nice, but where is it actually configured in a network? In firewall rules and access lists (ACLs). You know what such a rule looks like and why the list reads top-down from the Network security course. And there, almost every network starts the same way: an any-any rule, meaning ‘from anywhere to anywhere, any port’. It is born of the best intentions – something did not work, so the rule was temporarily widened to get traffic flowing, and it stayed. But any-any is not a rule, it is a disabled check: the firewall stands in the path yet lets everything through. Narrowing it means answering three questions: who (the source – a specific machine or segment, not ‘the whole network’), where (the destination – a specific server, not ‘all servers’) and what (the service and port – say only HTTPS on 443, not ‘everything’). So ‘any-any’ becomes ‘from the office segment to the accounting server, port 443’. The difference in impact is enormous: in the first case a captured employee computer reaches anything, in the second one service on one server. A useful guide when writing rules: start from the service, not the machine. Ask ‘what should this user really do?’ and permit exactly that. And describe your rules – a year later nobody will guess why that exception is there, so nobody will dare delete it.

Step by step

  1. An any-any rule lets everything through. The firewall stands in the path, but the check is effectively off.
  2. Narrowing has three steps. Who: the source is a specific machine or segment, not ‘the whole network’.
  3. Where: the destination is one specific server, not ‘all servers’. The rule scope shrinks dramatically.
  4. What: permit only the needed service and port – say HTTPS on 443. ‘Any-any’ becomes a concrete, describable rule.

Default deny as the default stance

NETFWSWSRVHRIOTGUESTdefault allow: what is not forbidden passes

Narrowing individual rules is not enough – the default stance also decides, that is what happens to traffic that no rule matches. There are two options and they are two different worlds. Default allow: whatever is not explicitly forbidden gets through. This approach condemns you to an endless list of bans – you would have to enumerate in advance every bad thing anyone will ever invent. Every new service, new port, new attack technique is a hole until someone notices and writes another ban. Default deny: whatever is not explicitly permitted is dropped. The list flips – instead of listing evil you enumerate the few good things that should pass. And since a company network needs surprisingly few things to work, that list is short, understandable and defensible. Default deny is therefore the default stance of Zero Trust and essentially a direct transcription of least privilege into firewall language. A practical note so it does not surprise you: turning default deny on hurts. The first time, something always stops working that nobody knew crossed the network – a silent update, monitoring, a backup agent. So it is done gradually: first the traffic is observed, then what is really needed is permitted, and only at the end the rest is closed. And one more forgotten thing: rules must be cleaned up. When a service ends, its rule stays and quietly holds a door open.

Step by step

  1. Default allow: what is not explicitly forbidden passes. You would have to list every bad thing in advance – impossible.
  2. Every new service, port or attack technique is a hole until someone notices and adds a ban.
  3. Default deny flips the list: you enumerate the few good things that should pass. A short, defensible list.
  4. Turn it on gradually: observe the traffic, permit what is needed, then close the rest. And clean up rules of retired services.

Rules that overlap

NETFWSWSRVHRIOTGUESTthe firewall reads top down and applies the first match

You have default deny and narrowed rules – and yet a hole you do not know about can still creep in. It arises from how a firewall evaluates rules: it walks the list top down and applies the first rule that matches the traffic. It never reads the rest. Hence the first trap: an overly broad rule at the top shadows narrow rules below it. If line one says ‘from the office network to anywhere, permit’ and line ten says ‘from the office network to the accounting server, deny’, that denial is never evaluated – the traffic was decided on line one. The rule looks perfectly fine sitting there and is easily missed in an audit. The second trap is the opposite: a never-used rule. It is either a leftover of a long-retired service or a mistake (a mistyped address, a changed port) – and in both cases it misleads you: you think you protect or permit something while the rule does not apply at all. A practical ordering that works: narrow exceptions at the top (specific denies first, then specific permits), general rules below, and default deny at the very end. Add two habits: describe your rules (who asked, why, until when) and regularly check which ones never match. In the simulator you will feel this on a task where the same traffic matches two rules at once – and the one that is higher decides.

Step by step

  1. The firewall walks the rules top down and applies the first that matches. It never reads the rest.
  2. Trap one: a broad ‘from office to anywhere, permit’ on top shadows the narrow deny below. The deny is never evaluated.
  3. Trap two: a never-used rule – a leftover of a retired service or a typo in the address. You think you protect, and it does not apply.
  4. A proven order: narrow exceptions on top, general rules below, default deny at the very end. And describe them.

▶ Open in the simulator

Lesson 3: Microsegmentation

Segment by role, not by floor

NETFWSWSRVHRIOTGUESTa flat network: nothing to write rules between

Rules are useless when the network is flat – because then there is nothing to write rules between. So the second half of least privilege is segmentation: splitting the network into smaller units (typically VLANs and subnets) whose traffic must pass a point where it can be checked. And here the first big design mistake happens: segments by floor or room. ‘A VLAN for the second floor, a VLAN for the ground floor’ looks tidy but means nothing for security – on the second floor an accountant, a camera and a printer sit side by side, so inside the segment things that have no business together talk freely. The right guide is: segment by role and sensitivity, not by geography. One segment holds what has the same purpose and the same level of trust: servers apart, user computers apart, IoT and cameras apart, guests apart, the management interface of network devices entirely apart. That is exactly what you see in the scene – four segments hanging off one L3 switch. Once roles are separated, meaningful rules can finally be written: ‘users may reach the application server on 443’, ‘IoT may go nowhere except its data collector’, ‘guests to the internet only’. And when one segment is then captured, the attacker hits a boundary where someone asks where they think they are going. That finer split – down to individual roles and servers, not just ‘inside and DMZ’ – is called microsegmentation.

Step by step

  1. In a flat network there is nothing to write rules between – it is all one unit talking directly.
  2. A design mistake: segments by floor. On the second floor an accountant sits next to a camera – security-wise it means nothing.
  3. The guide: segment by role and sensitivity. Servers apart, users apart, IoT apart, guests apart.
  4. Only now can meaningful rules be written: users to the application server on 443, IoT nowhere, guests out only.

Guest and IoT: where they must not go

NETFWSWSRVHRIOTGUESTa guest may do exactly one thing: out to the internet

Two segments hold a special place in practice, because they are where mistakes happen most: guests and IoT. Start with guests. From a security standpoint a guest is a device you know nothing about – not its updates, not its software, not what ran on it yesterday. So a guest may do exactly one thing: go out to the internet. Not to servers, printers, shared drives or management interfaces – and not to other guests either, which can be enforced by client isolation on the Wi-Fi (devices on the same network do not talk to each other). The guest network is a classic case where ‘almost right’ is not enough: a guest who reaches the printer reaches a device whose firmware nobody has updated since delivery. IoT is even more insidious because it does not look dangerous: cameras, sensors, smart bulbs, air conditioning, printers. What they share is a weak or nonexistent way to secure them: default passwords, outdated firmware, no updates, no antivirus. At the same time they are on the network permanently and nobody watches them. That is an ideal springboard for an attacker – quiet, forgotten, and yet inside. The rule for IoT is therefore: its own segment, out only to what it truly needs (typically one data collector or one vendor service), and no access to the rest of the network. And since a camera has no reason to talk to another camera, isolation inside the segment fits here too. The question to keep asking about both segments: what happens when an attacker takes exactly this device?

Step by step

  1. A guest is a device you know nothing about. It may do exactly one thing: go out to the internet.
  2. Not to servers, printers, shared drives or management interfaces – nor to other guests (client isolation).
  3. IoT does not look dangerous, yet it has default passwords and old firmware – and is on the network permanently. An ideal springboard.
  4. The IoT rule: its own segment, out only to what is needed (one collector) and no access to the rest of the network.

How many segments is too many

NETFWSWSRVHRIOTGUESTcoarse split: servers, users, IoT, guests, management

If segmentation is so useful, why not put every machine in its own segment? Because segmentation has a cost, and it grows faster than you would expect. Each further segment means another subnet, another interface on the L3 device, another set of rules – and above all more intersections: the more segments, the more pairs for which someone must decide what may pass. The practical outcome is always the same: a request comes in, nobody dares to decide, so more is permitted just in case – and within a year the fine split turns into a finely sliced flat network where everything may reach everything. That is the worst of both worlds: the complexity of microsegmentation without its benefit. A sensible level comes from two questions. First: does the level of trust differ? A camera and an accounting server, yes – they belong apart. Two accounting computers, no – they belong together. Second: can I write a rule for that boundary that I can defend? When nobody can answer ‘what exactly should cross here?’, the boundary does not belong there yet. A good approach is to start coarse (servers, users, IoT, guests, management) and split further only where it hurts – typically around the most sensitive data. Segmentation is not a contest for the number of VLANs; it is a tool to shrink the attacker’s reach to a size you can still administer.

Step by step

  1. Start coarse: servers, users, IoT, guests and management. That covers most real differences in trust.
  2. Each further segment adds a subnet, an interface and above all intersections – pairs where someone must decide what may pass.
  3. When the split is too fine, nobody dares decide and more is permitted. The result is a finely sliced flat network.
  4. Two questions: does the trust level differ? And can I write a defensible rule for that boundary? Otherwise it does not belong there.

▶ Open in the simulator

Lesson 4: Verify identity, not the socket

802.1X and RADIUS on Wi-Fi

NETFWSWSRVHRIOTGUESTthe shared Wi-Fi password is known to half the company

Back to the first principle: verify explicitly. In a classic network the ‘verification’ is a physical socket or knowing the Wi-Fi password – but a socket identifies nobody, and the shared Wi-Fi password (WPA2-Personal) is known to half the company, to former employees and to everyone it was ever forwarded to. Whoever connects gets the network. That is exactly what Zero Trust rejects. The answer is 802.1X: a standard where the device or user logs in before the port or Wi-Fi lets them onto the network at all. Three roles play in it. The client (your laptop) presents credentials or a certificate. The authenticator (the switch or access point) does not verify them itself – it just holds the door shut and passes them on. The authentication server, typically RADIUS, decides yes/no and sends the answer back. Only after a ‘yes’ does the port open. On Wi-Fi this is called WPA2/WPA3-Enterprise – instead of one shared password everyone has their own login (the Wi-Fi: security in depth course covers this in detail). Two practical consequences that make it worth the work: first, an employee leaving means revoking one account, not changing the password for the whole company; second, RADIUS can return not just yes/no but also which segment the device belongs to – so lessons 3 and 4 connect here: identity decides the placement, not the socket.

Step by step

  1. A shared Wi-Fi password or a socket identifies nobody. Whoever connects gets the network – Zero Trust rejects that.
  2. 802.1X: the client presents credentials or a certificate. The switch or access point does not verify them – it holds the door shut.
  3. The credentials travel to the authentication server (RADIUS). It decides yes/no and sends the answer back to the switch.
  4. Only after ‘yes’ does the port open. RADIUS can also return which segment the device belongs to – identity decides the placement.

VPN authentication against RADIUS

NETFWSWSRVHRIOTGUESTVPN: an encrypted tunnel from home into the network

The same logic applies to remote access. A VPN creates an encrypted tunnel from home or a hotel into the company network – and that is exactly why it is an extremely sensitive place: whoever passes the VPN ends up inside, precisely where the classic model stops checking. If the VPN verified only against a shared password or a local account on one box, you end up like with the shared Wi-Fi. So a VPN is typically wired to the same RADIUS as Wi-Fi and the ports: the user logs in with their company account, the VPN passes the query to the authentication server, and it decides. The benefit is organizational, not technical: one identity for all entrances. Block the account and the person gets in neither over Wi-Fi, nor over VPN, nor over a cable. One more thing must not be forgotten with remote access: multi-factor authentication (MFA) – a second proof on top of the password (a code from the phone, a hardware key). A stolen password alone is then not enough, and stolen passwords are the most common way in. And beware of the mistake Zero Trust explicitly holds against the classic design: a VPN by itself is not Zero Trust. When the tunnel delivers the user into a flat internal network where they may reach everything, you have merely extended the attacker’s cable into their living room. A VPN should end in a segment with rules – a remote user should have privileges just as narrow as in the office, not wider.

Step by step

  1. A VPN makes an encrypted tunnel inside. Whoever passes it ends up inside – hence an extremely sensitive place.
  2. The VPN asks the same authentication server as Wi-Fi and the ports: one identity for every entrance.
  3. Plus MFA: a second proof beyond the password. A stolen password alone then fails – and that is the most common way in.
  4. Beware: a VPN alone is not Zero Trust. If the tunnel ends in a flat network you only extended the attacker’s cable. It must end in a segment with rules.

What to do when the authentication server fails

NETFWSWSRVHRIOTGUESTthe authentication server failed – nobody gets in

When one authentication server decides every entrance to the network, you have raised a new question: what happens when it fails? The answer is unpleasant – without it nobody gets in. Wi-Fi rejects employees, ports stay shut, the VPN refuses logins. A security device has become a single point of failure for the whole company. The fix has two parts. The first is obvious: double the authentication server and configure both addresses on the devices (primary and backup) so they ask the second one on failure. The same resilience principle you know from course 14 – just applied to a security service, where it is easily forgotten. The second part is a decision you must make deliberately in advance: how should the network behave when even the second one is unreachable? You have two options and both cost something. Fail-closed: nobody gets in. Safe, but it means a blanket outage – and in operations that must not stop, the damage may exceed the risk. Fail-open: let them in without verification. Work continues, but at exactly that moment you have a network with no identity check – a state an attacker finds worth causing. The compromise most often chosen in practice is to admit devices into a heavily restricted segment: they get connectivity to the bare essentials, but no access to sensitive data. A sober conclusion: security that cannot be operated gets switched off sooner or later. Resilience of authentication is therefore part of its design, not an afterthought.

Step by step

  1. When the authentication server fails, nobody gets in: Wi-Fi, ports or VPN. A security device became a single point of failure.
  2. Part one of the fix: double the server and give devices a primary and a backup address – resilience as in course 14.
  3. Decide in advance: fail-closed (nobody in, blanket outage) or fail-open (admits unverified, a network with no identity check).
  4. The usual compromise: admit devices to a heavily restricted segment – essential connectivity, no sensitive data.

▶ Open in the simulator

Lesson 5: Assume breach

Blast radius: where the attacker reaches

NETFWSWSRVHRIOTGUESTtake the most vulnerable device: a hallway camera

The third principle – assume breach – has one very practical tool: the question ‘where does the attacker reach from here?’. The answer is called the blast radius: the set of everything reachable from one captured device. It is the best way to measure whether your segmentation is actually worth anything, because it does not ask ‘are we safe?’ (nobody can answer that) but ‘what specifically falls when this falls?’. The procedure is boring and effective: take a device – ideally the most vulnerable one, a camera, a printer, a guest laptop – and list everything it can open a connection to. Then repeat it for the DMZ server and for an ordinary employee computer. In a flat network the answer comes out the same every time: everything. In a well-split network you get three small and different lists – and that is the whole point. Segmentation cannot prevent the first breach (it arrives by phishing or a vulnerability; the network cannot stop that), but it decides whether it becomes an incident on one machine or on the whole company. This way of thinking also reverses the order of work: you do not start from what you want to permit, but from what you cannot afford to lose – and from there you ask who can reach it today. The most valuable data should have the smallest blast radius; when it turns out a hallway camera can reach the accounting server, you have just found your next task.

Step by step

  1. Take the most vulnerable device – a camera, a printer, a guest laptop – and ask: where does the attacker reach from here?
  2. In a flat network the answer is always the same: everything. That is the maximum blast radius.
  3. In a split network the list is short: the camera reaches its collector and nothing else. It will not prevent the breach, but it shrinks the damage.
  4. Reverse the order: start from what you cannot afford to lose and ask who can reach it today.

A decoy as an early warning

NETFWSWSRVHRIOTGUESTa normal network is noisy, the attacker hides in logs

Assuming breach has a second half: when the attacker is inside, you want to find out early. That is hard in practice, because a normal network is noisy – logs run to hundreds of thousands of lines and the attacker hides in them. But there is one strikingly simple trick: a decoy (honeypot). You place a device or service in the network that looks tempting – a server named something like ‘backups’ or ‘accounting’ – but which in reality has no legitimate purpose. No person and no application has any reason to connect to it. And that is precisely its strength: any connection attempt is suspicious. You need not distinguish normal from unusual behavior, you need not tune thresholds – zero is a clear line. Whoever touches the decoy is either looking around the network (an attacker) or misconfigured something (also worth knowing). A decoy is therefore a tool of early warning, not of defense: it stops nobody, but it tells you something is happening while you can still do something about it. Two practical notes. First: the decoy must be isolated and must hold nothing valuable – otherwise you added one more weak machine and helped the attacker. Second: it is pointless if nobody looks at its alerts. That holds generally – monitoring without response is just collecting data. Zero Trust does not end at configuring rules; it expects something to get through, and wants to see it.

Step by step

  1. You want to learn of a breach early, but a normal network is noisy and the attacker hides in the records.
  2. A decoy (honeypot): a device that looks tempting but has no legitimate purpose. Nobody has a reason to visit it.
  3. So any connection attempt is suspicious. No thresholds to tune – zero accesses is a clear line.
  4. Two conditions: the decoy must be isolated and hold nothing valuable – and someone must watch. Monitoring without response is just collecting data.

The topology check as hygiene

NETFWSWSRVHRIOTGUESTan exception ‘just temporarily’ and a leaver’s rules

A Zero Trust design has an unpleasant property: it decays on its own. Not because it is bad, but because the network lives. A project arrives and with it an exception ‘just temporarily’. A colleague leaves and their rules stay. Someone plugs a device into a socket that happens not to verify. A contractor gets access to one server and nobody removes it when the contract ends. Every single change looks harmless; after two years the careful design is again a flat network with a wall around it. Only one thing helps: regular hygiene – a repeated check, not a one-off project. In the simulator you have the topology check for this: it walks your network and flags weak spots that are easy to miss – a segment with no rules, a device that reaches where it should not, a guest network wired inside. Treat it as practice for what you do in a real network by hand or with a tool: walk the rule list (what never matched? what has no reason to exist?), walk the access list (who holds a privilege they do not use?) and walk the segment boundaries (what exactly crosses here and why?). A useful rhythm is simple: after every larger change, and then regularly even when nothing changed – those ‘unchanged’ periods are usually when the most exceptions piled up. Zero Trust is not a state you reach; it is maintenance.

Step by step

  1. The design decays on its own: an exception ‘just temporarily’, a leaver’s rules, a contractor’s access after the contract.
  2. Every change looks harmless, yet after two years the careful design is a flat network again with a wall around it.
  3. The topology check helps: it walks the network and shows weak spots – a segment with no rules or a guest network wired inside.
  4. The rhythm: after every larger change, then regularly, walk the rules, privileges and segment boundaries. Zero Trust is maintenance, not a state.

▶ Open in the simulator

Lesson 6: Zero Trust in practice

The journey from a flat network

NETFWSWSRVHRIOTGUESTsteps 1 and 2: find what is there and what talks

The last lesson is practical: you have a flat network and want Zero Trust out of it. Where to start so you do not stall after a week? A proven order of steps looks like this. 1) Find out what is actually in the network. You cannot protect what you do not know about – and every network holds a device nobody expected. 2) Find out what talks to what. Just observe the traffic for a while. Without it you write rules blindly and the first default deny takes the company down. 3) Separate the most sensitive and the most risky. Coarse segments: servers, users, IoT, guests, management. The biggest benefit for the least work. 4) Write rules between segments, permissive for now and even broad, but named – so it is visible what should cross. 5) Switch to default deny, segment by segment, not everywhere at once. Start where the traffic is best described – typically guests and IoT. 6) Add identity verification: 802.1X on ports and Wi-Fi, VPN and MFA against the same authentication server. 7) Build monitoring and rehearse the response. Finally 8) repeat – reviewing rules and privileges is regular work. Notice that the first five steps need no new product: they are done with the rules and segments you already have. And notice where identity verification sits: sixth, because without segments and rules it has nothing to enforce. The most common mistake is to start from the end – buy a tool and hope it decides for you what should be allowed.

Step by step

  1. Steps 1 and 2: find out what is in the network and just observe the traffic for a while. Otherwise you write rules blindly.
  2. Steps 3 and 4: coarse segments (servers, users, IoT, guests, management) and named rules between them.
  3. Step 5: switch to default deny segment by segment – start where traffic is best described (guests, IoT).
  4. Steps 6 to 8: identity verification (802.1X, VPN, MFA), monitoring, then repeat. The first five steps need no new product.

What Zero Trust is not

NETFWSWSRVHRIOTGUESTno box installs Zero Trust for you

There is a lot of marketing around Zero Trust, so let us be clear about what Zero Trust is not – it will save you money and disappointment. It is not a product. There is no box or license after whose deployment you have Zero Trust. It is a way of designing, assembled from things you already know: segmentation, least-privilege rules, identity verification, monitoring. Tools will help, but nobody makes the ‘who may go where’ decision for you. It is not just a VPN. A VPN solves encrypted transport and entry from outside – it does not solve what you may do once inside. When the tunnel ends in a flat network, it is castle and moat with a longer moat. It is not just MFA. A strong login is excellent and saves a lot of trouble, but it is only the first of three principles; after logging in, where the network lets you still applies. It is not ‘distrusting people’. The name misleads – it is not about suspecting employees, but about trust not being derived from location and not being granted permanently. It is not a one-off project, as you saw with hygiene. And finally: it is not all or nothing. Separating guests and IoT and closing a few needless paths is an enormous gain even if you have no 802.1X and never will. Soberly: Zero Trust is a direction the network moves in step by step – and every step counts on its own.

Step by step

  1. Not a product: there is no box whose deployment gives you Zero Trust. Nobody makes the ‘who may go where’ decision for you.
  2. Not just a VPN: the tunnel solves encrypted transport and entry. Ending in a flat network, it is castle and moat with a longer moat.
  3. Not just MFA: a strong login is the first of three principles. After logging in, where the network lets you still applies.
  4. Not all or nothing: separating guests and IoT is a big gain even without 802.1X. Every step counts on its own.

A checklist for your design

NETFWSWSRVHRIOTGUESTidentity: one source for cable, Wi-Fi and VPN, plus MFA

To close, a checklist you can take to any network design or review. Identity: Is every entrance (cable, Wi-Fi, VPN) verified against one identity source? Does remote access have MFA? Are privileges removed when a person leaves or a contract ends? Segments: Are they split by role and sensitivity, not by floor? Do guests, IoT and management interfaces have their own segment? Is the guest network really internet-only? Rules: Is default deny in effect? Is every rule narrow (source, destination, service) and described? Does a broad rule on top shadow narrow ones below? Are there rules that never matched? Reach: If I captured a camera, a guest laptop or the DMZ server, where would I get from there? Do the most valuable data have the smallest blast radius? Operation and resilience: Has the authentication server become the one box the whole company hangs on? Do I know what happens when it fails? Does anyone look at the alerts? Have I ever rehearsed the response? A final piece of advice to take away: pick the one answer that hurt most today and fix it. Zero Trust is not done at once – it is done by making that list one missing boundary shorter next time. Congratulations on finishing the course; now try it in the simulator on the challenge where a guest is wired where they should not be.

Step by step

  1. Identity: is every entrance verified against one source? Does remote access have MFA? Are privileges removed on departure?
  2. Segments: split by role and sensitivity? Do guests, IoT and management have their own? Is the guest network really internet-only?
  3. Rules: is default deny in effect? Is each one narrow (source, destination, service) and described? Does a broad rule shadow the narrow ones?
  4. Reach and operation: where do I get from a captured camera? What if authentication fails? Does anyone watch the alerts? Pick one answer and fix it.

▶ Open in the simulator