StealthTech
A defense contractor in our Tampa client base once asked us why their firewall, VPN, and antivirus stack — the same three-legged setup that had protected them for over a decade — suddenly wasn’t good enough for CMMC Level 2. The honest answer was that it never really was. It just hadn’t been tested by an assessor, a ransomware crew, or a compromised subcontractor credential yet. That conversation is happening across manufacturing floors, engineering firms, and back offices right now, and it comes down to a single architectural question: do you trust the network, or do you verify everything on it?
That question is the entire difference between traditional perimeter security and zero trust. It’s not a marketing rebrand of the same controls. It’s a different assumption about where the threat lives, and for a defense contractor sitting on Controlled Unclassified Information, getting that assumption wrong has consequences that go well beyond a bad audit.
What “Traditional” Network Security Actually Assumed
Perimeter-based security was built for a world where the office had walls, the servers sat in a closet down the hall, and remote access meant one person occasionally dialing in from a hotel. The model draws a hard line between “inside” and “outside.” Once a device authenticates onto the internal network — via VPN, via a domain login, via a trusted IP range — it’s largely free to talk to whatever else lives inside that boundary. Firewalls guard the edge. Everything behind the edge is implicitly trusted.
That assumption made sense when the edge was a real, physical thing. It stopped making sense the moment employees started working from home, contractors started connecting from their own laptops, engineering teams started pushing CAD files to cloud storage, and phone systems moved off copper and onto the same IP network as everything else — a shift we cover in more detail in our breakdown of VoIP versus traditional phone systems. The perimeter didn’t disappear. It just stopped being a meaningful control point, because most of the traffic that matters now never crosses it.
What Zero Trust Actually Means, Stripped of the Marketing
Zero trust is not a product you buy. It’s an operating principle: no user, device, or application is trusted by default, regardless of whether it’s sitting inside the office or connecting from a home network in another state. Every request for access gets evaluated on its own merits — who is asking, from what device, in what condition, requesting access to what specific resource — every single time, not once at login.
In practice this means identity becomes the primary control plane instead of network location. It means a device that hasn’t had its patches applied in three weeks gets flagged or blocked, even if the user’s password is correct. It means a compromised credential doesn’t automatically hand an attacker the rest of the network, because access is scoped narrowly to what that specific account needs, not to everything reachable once you’re “inside.” NIST codified this thinking in SP 800-207 and folded expectations around it directly into the access control and identification requirements of NIST SP 800-171 Revision 3, which is the document your assessor will actually be scoring you against.
Why CMMC Pushes You Toward Zero Trust Whether You Name It That or Not
Nobody in the CMMC ecosystem is required to build a formally labeled “zero trust architecture” to pass a Level 2 assessment. But look closely at what the practices under NIST 800-171 actually demand — multi-factor authentication on privileged and remote access, least-privilege enforcement, session termination after periods of inactivity, network segmentation between CUI enclaves and everything else — and you’re looking at zero trust controls by another name. The DoD’s CMMC Program didn’t invent these requirements; it inherited them from a federal risk framework that had already moved past the perimeter model years earlier.
This matters practically because contractors sometimes treat compliance and architecture as separate projects — hire someone to write the System Security Plan, keep the existing network as-is, patch the gaps with policy documents. That approach produces a paper SSP that doesn’t match reality, and it’s exactly the kind of mismatch that shows up during a DFARS 252.204-7012 incident reporting review after a breach, when investigators start asking why the documented controls didn’t actually stop the attacker from moving laterally. Our compliance team sees this gap constantly: the SSP says segmentation exists, but the firewall rules tell a different story.
Where the Perimeter Model Keeps Failing Contractors
The failure pattern is consistent enough that we can predict it before we run the assessment. A contractor has a solid perimeter firewall, a VPN for remote staff, and antivirus on every endpoint. Then one of the following happens: a subcontractor’s laptop gets phished and the attacker pivots from that single foothold into engineering file shares, because once inside the VPN there was nothing stopping lateral movement. Or an employee’s credentials get reused from a breached consumer site, and because the internal network trusted any authenticated session equally, the attacker walks straight to the accounting server. Or a legacy printer or IoT device on the same flat network becomes the entry point nobody thought to isolate.
None of these are exotic attacks. They’re the default outcome of a flat network where “authenticated” is treated as synonymous with “safe.” CISA’s guidance on nation-state cyber actors specifically calls out defense industrial base companies as targets precisely because this pattern is so exploitable — a single compromised vendor credential can be the entry point into a much larger supply chain. Manufacturing and engineering firms, which tend to run older OT and CAD systems that can’t always be patched on a modern cadence, are especially exposed to this; it’s a big part of why our manufacturing and engineering clients need segmentation strategies that account for equipment that simply can’t run current agents.
Identity Becomes the New Perimeter
If there’s one shift that defines the move to zero trust, it’s this: identity verification replaces network location as the thing you actually secure. That sounds abstract until you look at what it changes day to day. Multi-factor authentication stops being a checkbox for remote access and becomes mandatory for any privileged action, anywhere. Conditional access policies evaluate device health, geographic anomalies, and behavioral signals before granting a session, not just a correct password.
This is also where a lot of contractors get tripped up by a control they thought they’d already solved. MFA fatigue attacks — where an adversary spams push notifications until an exhausted employee finally taps “approve” just to make the alerts stop — have become one of the most common ways attackers defeat MFA that was implemented but never hardened against social engineering, something we walked through in detail in our piece on MFA fatigue attacks. It’s also why more contractors are evaluating passkeys as a replacement for passwords entirely, since phishing-resistant authentication closes a gap that push-based MFA leaves wide open. Identity isn’t a one-time gate anymore — it’s a continuous signal that either supports zero trust or quietly undermines it.
Segmentation, Least Privilege, and the Legacy System Problem
Two principles do most of the practical work in a zero trust architecture, and they’re worth separating out because contractors often implement one without the other.
- Microsegmentation breaks the network into small, isolated zones so that compromising one segment — a guest Wi-Fi network, a shop-floor OT device, a single workstation — doesn’t grant automatic reach into CUI environments or financial systems. This is the direct answer to the lateral-movement failure pattern described above.
- Least-privilege access ensures every account, human or machine, has only the permissions required for its specific role, re-evaluated on a schedule rather than accumulated indefinitely. Most privilege creep happens quietly, over years, as employees change roles and nobody revokes the old access.
The honest complication is legacy infrastructure. A machine shop running a fifteen-year-old CNC controller, or a firm still dependent on an on-premises application that can’t support modern identity federation, can’t simply bolt zero trust onto systems that were never designed for continuous verification. This is usually where a co-managed IT arrangement earns its keep — an internal team keeps running day-to-day operations while an outside partner builds the segmentation and monitoring layer around the systems that can’t be modernized on any reasonable timeline.
The Real Cost and Operational Trade-Offs
Zero trust isn’t free, and pretending otherwise sets contractors up for a rough implementation. It typically costs more up front than a traditional perimeter model, because it requires identity infrastructure, endpoint detection tooling, and segmentation work that a flat network never needed. It also adds friction for users in the early months — more authentication prompts, more device compliance checks — before the policies get tuned enough to be invisible in daily use.
But the traditional model’s costs are just deferred, not avoided. A flat network is cheaper until the day a single compromised account turns into a full-network incident, at which point the backup and data recovery bill, the incident response bill, and the reputational cost with your prime contractor dwarf what proper segmentation would have cost. We’ve written about this trade-off specifically in the context of immutable backups surviving ransomware — a strong zero trust posture reduces how often you need that last line of defense, but it doesn’t replace the need for it entirely. The two are complementary, not either/or.
A Realistic Migration Path, Not a Rip-and-Replace
Nobody rebuilds their entire network architecture over a weekend, and any vendor who tells you that’s the plan hasn’t done this before. The contractors who migrate successfully treat it as a sequence, not an event.
Start with identity: enforce MFA everywhere, eliminate shared accounts, and get a real inventory of who has access to what. Move next to device posture — no unmanaged, unpatched device gets trusted, regardless of who’s logging in from it. Then segment the network around your actual CUI boundary first, since that’s what an assessor is going to scrutinize, before expanding segmentation further. Layer in continuous monitoring and logging so anomalous access patterns get flagged instead of discovered three months later. A vCIO is often the right role to own this sequencing, because it requires balancing security priorities against budget cycles and operational disruption — something we cover in more depth in what a vCIO actually does.
It’s also worth flagging that zero trust extends past the network layer into how employees use tools day to day. A segmented network doesn’t stop an engineer from pasting a proprietary drawing into a public AI chatbot, which is its own exposure vector we’ve addressed directly in our guide to shadow AI security and in building a workable AI usage policy. Zero trust as an architecture and zero trust as an operating culture need to move together.
Which Model Actually Wins for a Modern Business
For a defense contractor holding CUI, this isn’t a close call. Traditional perimeter security assumes a threat model that stopped matching reality years ago, and CMMC assessors are explicitly scoring against controls that only make sense under a zero trust framework. Firms in less regulated industries have more room to phase the transition, but the direction of travel is the same everywhere — cloud adoption, remote work, and third-party access have already dissolved the perimeter whether or not the network diagram admits it.
That doesn’t mean every organization needs a full zero trust build on day one. A ten-person nonprofit and a two-hundred-person manufacturer have very different risk profiles and budgets, which is part of why we scope security differently across healthcare, legal, finance, and non-profit clients rather than selling the same stack to everyone. What doesn’t change is the underlying logic: verify explicitly, assume breach, and stop treating “inside the network” as a synonym for “safe.” CISA’s guidance on strengthening resilience against supply chain compromise makes the same point from a different angle — in an interconnected vendor ecosystem, trusting a network segment because it’s internal is no longer a defensible security posture for anyone handling sensitive data.
Conclusion
The shift from traditional network security to zero trust isn’t a trend defense contractors can wait out. It’s a direct response to how attackers actually move once they get a foothold, and it’s increasingly how CMMC assessors evaluate whether your controls hold up under scrutiny. Whether you’re based near our Boston, Tampa, or Sarasota offices, the migration path looks the same: identity first, device posture second, segmentation around your CUI boundary third, and continuous monitoring running underneath all of it. Our cybersecurity and managed IT services teams build this incrementally, around your existing infrastructure and your assessment timeline, rather than asking you to gamble on a rebuild.
If your organization is planning its CMMC compliance journey, contact Stealth Technology Group today at (617) 903-5559 or visit the website to learn how modern cybersecurity infrastructure can accelerate your path toward certification readiness.
