Ever wonder why your company's network seems fine one day and falls over the next? Or why a "simple" printer install turns into a two-hour fire drill? On the flip side, turns out, most people picture IT as one big blob of computers and cables. It isn't Simple, but easy to overlook..
Counterintuitive, but true.
When we talk about the seven domains of a typical IT infrastructure, we're really talking about the invisible boundaries that decide who can touch what, where the risks live, and why your help desk sounds tired. Miss one of these domains and you don't just get a slow laptop — you get a breach, a outage, or a compliance letter you really didn't want.
Here's the thing — once you see these seven domains, you can't unsee them. Let's walk through what they are, why they matter, and where most teams quietly screw them up.
What Is a Typical IT Infrastructure (and Those Seven Domains)
A typical IT infrastructure isn't just servers in a closet. It's the whole ecosystem: the machines, the people, the rules, and the connections between all of it. The seven domains model is a way to slice that ecosystem into manageable chunks so you can actually secure and manage it That alone is useful..
The short version is this: there are seven places where users, data, and systems meet. Each one has its own risks and its own controls. The model most old-school security folks use looks like this:
- User Domain — the people
- Workstation Domain — the desktops and laptops
- LAN Domain — the local network
- LAN-to-WAN Domain — the edge, where you hit the internet
- WAN Domain — the wide-area stuff, including cloud and remote sites
- Remote Access Domain — VPNs and folks working from anywhere
- System/Application Domain — the servers, databases, and software that run the business
The User Domain
Basically the humans. Employees, contractors, that intern who clicks everything. So naturally, a sticky note under the keyboard. A phishing email. But a stolen password. Day to day, in practice, this is where most trouble starts. The user domain is the only one you can't patch with software.
The Workstation Domain
Every laptop, every desktop, every tablet issued to a user. This is where local policies, endpoint protection, and OS updates either hold or fall apart. I know it sounds basic — but unpatched workstations are still how a lot of ransomware gets in.
The LAN Domain
Your local area network. And the place where everything inside the building talks. Switches, internal Wi-Fi, file shares, printers. If segmentation is bad here, one infected machine becomes everyone's problem.
The LAN-to-WAN Domain
The gateway. Worth adding: firewalls, proxies, the router that says "you may exit the building. " This is the choke point. It's also where most small businesses either over-trust a $50 router or drown in rules nobody understands.
The WAN Domain
Wide area network — think site-to-site links, MPLS, and increasingly the public internet as your backbone. Cloud providers live out here. So does most of your supply chain That's the whole idea..
The Remote Access Domain
VPN, zero-trust tunnels, dial-up if you're ancient. Day to day, anyone not in the building but touching your stuff. After 2020, this domain stopped being optional and became the front door Surprisingly effective..
The System/Application Domain
The core. Also, domain controllers, databases, ERP systems, web apps. If this domain fails, the business doesn't just slow down — it stops That's the part that actually makes a difference..
Why It Matters / Why People Care
Why does this matter? " But a firewall doesn't stop a user from wiring money to a fake invoice. Think about it: they buy a firewall and think they're "secure. Because most people skip it. And a great endpoint tool doesn't help if your WAN config leaks data to the open internet Most people skip this — try not to..
Real talk: when something breaks, it almost always crosses a domain boundary. The phishing email (User) hits the laptop (Workstation), rides the LAN to the gateway (LAN-to-WAN), reaches a cloud app (WAN), and steals from the finance system (System/Application). That's five domains in one bad afternoon The details matter here..
Understanding the seven domains of a typical IT infrastructure lets you ask better questions. Still, where's our weakest boundary? Who owns the remote access policy? So why is the guest Wi-Fi on the same VLAN as payroll? You can't fix what you can't frame That alone is useful..
This is the bit that actually matters in practice.
And here's what most guides get wrong — they treat these as separate boxes. Even so, they're overlapping trust zones. Worth adding: they aren't. A mistake in the User Domain echoes into System/Application whether you documented it or not.
How It Works (or How to Actually Use the Model)
The meaty part. You don't need a certification to use this. You need a whiteboard and honesty.
Step 1: Map Your Domains
List every domain and what lives in it. Now, for User Domain, name the roles. For Workstation, count the devices and their OS. For LAN, draw the VLANs. Don't skip the boring ones. Most teams "know" their WAN until they realize half their SaaS tools aren't in any inventory But it adds up..
Step 2: Find the Boundaries
Where does one domain hand off to another? Workstation to LAN is network access. Write these down. On top of that, remote Access to System is your VPN auth. But user to Workstation is login control. LAN to WAN is your firewall and DNS. Practically speaking, that's your risk surface. Boundaries are where attackers live.
Step 3: Assign Ownership
Every domain needs a human. Not a team — a human. "The network team" is not ownership; "Jordan owns LAN-to-WAN rules" is. When a domain has no owner, it gets ignored until it burns.
Step 4: Control Each Domain Proportionally
You don't need military-grade controls on the guest printer VLAN. A shared folder with cat memes doesn't need MFA. But the System/Application Domain should have logging, hardening, and access reviews. Match the control to the blast radius. Your SQL server does That's the whole idea..
Step 5: Test Cross-Domain Paths
This is the part most audits miss. Don't test the firewall alone. Still, test: can a compromised workstation reach the domain controller without alerting anyone? And can a remote user pivot from VPN into payroll? Simulate the path, not the box.
Step 6: Review When Things Change
New office? New app? Because of that, new CEO with a personal iPad? Also, that's a domain change. Still, the seven domains aren't static. They shift when your business does. Worth knowing: most "sudden" outages were domain changes nobody reviewed.
Common Mistakes / What Most People Get Wrong
Honestly, this is the part most guides get wrong because they list the domains and stop. Here's where it actually falls apart in the real world.
Mistake 1: Ignoring the User Domain. Teams spend thousands on SIEM tools and zero on training. The user is the softest target and the least funded. That's backwards Most people skip this — try not to..
Mistake 2: Treating Remote Access as an Afterthought. "We'll just use the same VPN we bought in 2014." Meanwhile your workforce is fully distributed and your VPN has three users in the admin group who left the company.
Mistake 3: Flat LANs. Everything on one network because "it's simpler." It's simpler right up until ransomware encrypts the file server and the reception PC at the same time Most people skip this — try not to. Nothing fancy..
Mistake 4: Cloud blindness in the WAN Domain. "It's in AWS, so it's not our network." Wrong. It's your data, your users, your liability. The WAN domain didn't shrink — it exploded.
Mistake 5: No ownership of System/Application. Everyone assumes "ops handles it." Ops assumes the vendor handles it. The vendor assumes you configured it. And here we are Not complicated — just consistent..
Practical Tips / What Actually Works
Skip the generic advice. Here's what earns its place.
- Name a domain owner this week. Even if it's informal. You'll be ahead of most mid-size companies.
- Draw the cross-domain paths once a quarter. Not the boxes — the arrows. That's where risk hides.
- Put MFA on the System/Application Domain first, then Remote Access, then User admin roles. Don't boil the ocean; start where the blast radius is worst.
- Segment the LAN like you mean it. A separate VLAN for guest, for corporate, for IoT. Printers should not be able to talk to your finance
servers.
-
Run a tabletop exercise that starts with a user clicking a bad link. Watch how fast it moves across domains if you’ve done nothing else on this list. Most teams are shocked at how few hops it takes.
-
Audit dormant accounts every 90 days. Especially in Remote Access and System/Application. Old service accounts are the skeleton keys nobody talks about The details matter here. But it adds up..
-
Document the exceptions, not just the rules. “We allow port 445 from VLAN 10 to the file server because of legacy app X” beats a clean policy that nobody follows under pressure.
Conclusion
The seven domains of a typical IT infrastructure aren’t a checklist you complete once and forget. They’re a living map of where your risk actually lives — and more often than not, it lives in the gaps between domains, not inside them. The organizations that handle incidents well aren’t the ones with the biggest security budgets; they’re the ones who know who owns what, how data moves, and what happens when one domain gets compromised. Start small: assign owners, trace the paths, fix the flat networks. Consider this: you don’t need perfection. You need visibility and a plan that survives contact with reality.
Most guides skip this. Don't.
