StealthTech
Ask most IT teams to draw their attack surface and you’ll get a diagram full of firewalls, VPN concentrators, and endpoint agents. Almost none of them draw a browser tab. That’s the gap adversaries have been exploiting for the better part of a decade, and it’s the gap that matters most right now for defense contractors carrying CUI, because the browser has quietly become the primary interface between your workforce and the internet — email, CRM, ERP, cloud storage, contract portals, even remote desktop sessions all run through it. Secure the network and leave the browser alone, and you’ve hardened the wrong layer.
This isn’t a theoretical concern dressed up for a compliance audience. Browser-based attacks — malicious extensions, credential-harvesting login pages, drive-by exploits against unpatched rendering engines, session token theft — now account for a disproportionate share of initial access incidents tracked by CISA. For an organization operating under DFARS 252.204-7012 reporting obligations, a compromised browser session isn’t just an inconvenience. It’s a potential cyber incident with a 72-hour clock attached.
The Perimeter Moved and Most Security Programs Didn’t Follow
A decade ago, the browser was a window onto the internet. Today it’s an application runtime. Google Workspace, Microsoft 365, Salesforce, most ERP and PLM platforms, and nearly every SaaS tool your engineering or finance team touches now run natively in a browser tab rather than a locally installed client. That shift changed what the browser actually is from a security standpoint — it’s no longer a viewer, it’s the place where authentication happens, where session tokens live, where files get uploaded and downloaded, and where copy-paste moves data between sanctioned and unsanctioned destinations.
Traditional network security controls were built for a world of installed applications and defined egress points. A next-gen firewall can inspect traffic leaving your network, but it has almost no visibility into what happens inside an authenticated browser session — which extension just read the DOM of your CRM page, which script injected itself into a login form, which “helpful” productivity add-on is quietly exfiltrating clipboard contents. Our team sees this blind spot constantly across managed IT services engagements: organizations with mature network security postures that have never once inventoried what’s installed in their employees’ browsers.
Part of the reason this gap persists is organizational. Network security typically reports up through infrastructure or a security operations function with dedicated tooling, budget, and metrics. Browser security, when it’s owned by anyone at all, usually falls to whoever manages endpoint configuration as an afterthought bolted onto a broader device management policy. Nobody owns it as a discipline in its own right, which means nobody’s measuring extension sprawl, nobody’s tracking which profiles have sync enabled to personal Google or Microsoft accounts, and nobody’s correlating browser telemetry with the rest of the security stack. That ownership gap is usually the first thing worth fixing, before any tooling decision gets made.
CUI Doesn’t Stay in Approved Systems — It Follows the User
Every CMMC program starts with a CUI boundary: identify where controlled unclassified information lives, then wrap controls around that boundary. The boundary looks clean on a network diagram. In practice, CUI moves the moment a user copies a spec sheet into an email draft, uploads a drawing to a personal cloud storage tab open next to the approved one, or pastes a contract clause into an AI writing assistant to “clean up the language.” None of that requires malware. It requires a browser with more than one tab open and a user who doesn’t realize the boundary just moved with them.
This is the argument for treating browser governance as a genuine compliance control rather than a productivity nice-to-have. NIST SP 800-171 requires organizations to control the flow of CUI in accordance with approved authorizations, and a browser with unrestricted access to consumer file-sharing sites, unmanaged AI tools, and personal webmail is a flow-control failure waiting to happen — whether or not anyone acted with bad intent. We wrote about this exact failure mode in our piece on shadow IT and unauthorized apps, and the browser is where most shadow IT actually lives, one tab away from the systems you already govern.
Extensions Are Third-Party Code Running Inside Every Session
If you wouldn’t let an employee install unvetted software on a server holding CUI, you shouldn’t let them install unvetted extensions in the browser that authenticates to every SaaS system your business runs on. Yet browser extensions routinely get a permissions pass that would never survive a change-management review anywhere else in the environment. A grammar checker, a coupon finder, a PDF converter — each one typically requests the ability to read and modify data on every website the user visits, which in practice means it can see session cookies, form contents, and anything rendered on screen.
Extension marketplaces have been repeatedly compromised through ownership transfers, where a legitimate extension with an established user base gets sold to a bad actor who pushes a malicious update through the auto-update mechanism users never see. The extension your team approved eighteen months ago isn’t necessarily the same code running today. Any browser security program worth the name needs an allowlist model — approved extensions only, centrally managed, reviewed on a cadence — rather than a free-for-all governed by whatever looks convenient in the marketplace.
Credential Theft Has Moved Past Malware
Ransomware groups and nation-state actors alike have largely abandoned the loud, malware-heavy intrusion in favor of something far quieter: stealing a session token or a set of credentials directly from the browser and walking in the front door. CISA’s guidance on nation-state cyber actors has repeatedly flagged credential harvesting through convincing look-alike login pages as a primary technique against organizations with defense industrial base exposure, precisely because it bypasses endpoint detection tools built to catch executables, not phishing pages rendered in a browser tab.
The mechanics are almost boring in their simplicity. A user receives a link, the page renders a pixel-perfect replica of a Microsoft 365 or VPN login screen, credentials get typed in, and the attacker now holds a valid session — often without triggering a single alert, because nothing was “installed.” Multi-factor authentication helps, but push-fatigue attacks and adversary-in-the-middle proxy kits have shown that traditional MFA isn’t the finish line it once was. We cover the shift toward phishing-resistant methods in more depth in our article on passwordless authentication, which is increasingly the more durable answer than layering more prompts on top of a password.
Shadow SaaS Turns Every Employee Into an Unmanaged Access Point
Ask a compliance lead which servers hold CUI and you’ll get a confident, specific answer. Ask which of the forty or fifty SaaS tools employees have logged into through the browser this quarter actually touch sensitive data, and the confidence usually evaporates. Every one of those logins happened through a browser, frequently using a personal email as the account identifier, frequently with no security team visibility at all. This is the same blind spot we detailed in our guide to SaaS security posture management, and the browser is the single vantage point where that sprawl can actually be seen and controlled, because every one of those unmanaged logins passes through it.
A handful of browser-level indicators tend to surface the highest-risk gaps fastest, and this is one of the few places a short list genuinely earns its space:
- Unmanaged extensions with broad site-access permissions installed outside a central policy
- Personal cloud storage or webmail accessible from the same browser profile used for work systems
- Password reuse between sanctioned SaaS tools and unvetted third-party services, visible through browser-stored credentials
- File uploads to AI writing or coding assistants that haven’t gone through a vendor security review
- Session tokens with no expiration tied to idle time, letting a stolen cookie stay valid indefinitely
None of these show up on a network security scan. All of them show up the moment someone actually looks at browser configuration and activity across the fleet.
AI Tools Have Added a New Exfiltration Path Nobody Budgeted For
Generative AI assistants have become the fastest-growing category of browser-based data exposure, and most organizations still treat them as a productivity question rather than a security one. An engineer pastes a proprietary drawing spec into a browser-based AI tool to get help drafting documentation. A finance employee uploads a spreadsheet to summarize it faster. None of this looks like an attack, and none of it requires bypassing a single network control, because it’s happening inside a browser tab the user is fully authorized to access. The data simply leaves through a door nobody thought to lock, because the door doesn’t look like a door — it looks like a text box.
This is precisely where AI governance and browser governance need to converge rather than sit in separate policy documents. Knowing which AI tools are permitted, which have been vetted for data handling practices, and which browser-level controls prevent uploads to unapproved destinations is now a baseline expectation, not an advanced maturity item. It’s a conversation worth having as part of any broader AI integration planning, because the tools your team adopts to move faster are only a net positive if they don’t simultaneously widen the CUI boundary in ways nobody documented.
Isolation, Not Just Inspection, Is Where Zero Trust Actually Lands
Zero trust gets discussed mostly at the network and identity layer — segment the network, verify every request, never trust based on location. The browser is where that philosophy either gets enforced or quietly abandoned, because it’s the layer where an authenticated, “trusted” user actually interacts with untrusted web content every hour of the workday. Browser isolation technology — rendering risky or unknown sites in a sandboxed, disposable environment rather than directly on the endpoint — closes a gap that endpoint detection and response tools were never designed to cover, since EDR is largely built to catch file-based threats, not a malicious script executing entirely within a rendering engine.
Combined with managed browser policies — restricting which extensions can install, which sites can accept file uploads, which profiles can sync personal and work data — isolation turns the browser from an open door into a controlled entry point. This is squarely the kind of layered control our cybersecurity practice builds around, because it addresses the specific reality that most of a modern workday happens in a browser tab rather than a locally installed application.
Patch Cadence: Browsers Update Faster Than Most Policies Account For
Browser vendors ship security patches on a rolling, sometimes weekly basis, which is a strength against known exploits and a genuine operational challenge for any organization trying to maintain a documented patch management program. A browser that auto-updates silently in the background can drift out of policy compliance without anyone noticing, or worse, a managed environment that disables auto-update for stability reasons can leave a known, actively exploited vulnerability unpatched for months. NIST’s National Vulnerability Database logs browser engine vulnerabilities with sobering regularity, and a meaningful share carry active exploitation in the wild before a patch ever reaches end users.
The fix isn’t complicated in principle: centrally manage browser update policy the same way you manage operating system patching, verify version compliance across the fleet on a defined cadence, and treat an out-of-date browser build as the same category of finding as an unpatched server. It’s a smaller lift than most organizations assume once the tooling is in place, but it requires someone to actually own it, which is where a lot of internal IT teams — stretched thin already — start to fall behind.
There’s a second, less obvious dimension to patch cadence: extension updates ship on their own schedule, entirely separate from the browser itself, and most organizations have zero visibility into that layer at all. A browser can be fully patched and still be running an extension with a known vulnerability that was disclosed months ago, simply because nothing in the environment is tracking extension versions the way it tracks operating system builds. Any mature configuration baseline needs to account for both layers, not just the one that shows up in a standard patch report.
What CMMC Actually Expects at the Browser Layer
CMMC doesn’t have a control literally titled “browser security,” which is exactly why organizations underinvest here — it’s easy to assume the requirement doesn’t exist because the word doesn’t appear in the assessment guide. But several NIST 800-171 control families reach directly into browser behavior once you trace them through, and this is the second place a structured list is worth the space:
- Access Control (AC) — governs whether unmanaged extensions and unauthorized SaaS logins constitute uncontrolled access paths to CUI
- System and Communications Protection (SC) — covers encrypted sessions, boundary protection, and the isolation of publicly accessible content from internal systems, all of which browsers touch directly
- Configuration Management (CM) — requires a defined, monitored baseline, which extends to browser build version, approved extension lists, and profile settings
- Identification and Authentication (IA) — ties directly to how credentials and session tokens are protected against theft at the browser level
- Risk Assessment (RA) — expects organizations to actually identify browser-borne threats rather than assume the firewall has it covered
Assessors increasingly ask pointed questions about extension governance and browser configuration management during Level 2 assessments, not because it’s a checkbox item but because it’s become one of the more common places evidence collection reveals a gap between documented policy and actual practice. A System Security Plan that describes access controls in detail but never mentions browser configuration or extension management reads, to a trained assessor, like a plan written for a network that stopped existing five years ago. Our SaaS vendor evaluation guide covers a related angle worth reading alongside this — the browser-based tools your team adopts need the same security scrutiny as anything installed locally, and the choice of Microsoft tenant, which we break down in our GCC High versus GCC comparison, shapes what browser-level controls are even available to you in the first place.
Building a Program That Survives Contact With an Assessor
A browser security program that holds up under assessment scrutiny starts with an honest inventory: what browsers are in use, what versions, what extensions, and which profiles have access to CUI-adjacent systems. From there it needs policy — centrally managed extension allowlisting, enforced update cadence, session timeout standards, and isolation for high-risk browsing — backed by monitoring that actually surfaces drift rather than assuming policy equals practice. This is the same discipline that underpins effective vulnerability management under CMMC: a documented process means nothing to an assessor without evidence that it’s actually enforced.
For organizations without the internal bandwidth to own this end to end, a co-managed IT arrangement can extend an existing internal team’s capacity without replacing it, while a full vCIO services engagement builds browser governance into the broader security roadmap alongside budgeting and framework alignment. Either path beats the default most organizations fall into, which is treating the browser as outside the scope of IT security entirely because it came pre-installed on the operating system rather than procured and reviewed like everything else.
Browser security also doesn’t sit in isolation from the rest of the stack. It intersects with cloud transformation decisions about where data actually lives, with AI integration choices about which tools employees are permitted to paste sensitive content into, and with backup and data recovery planning for the scenario where a compromised session does result in data loss or encryption. Engineering firms managing CAD files, manufacturing operations tracking production data, and any organization in the manufacturing or engineering sectors handling CUI carry particular exposure here, since so much of that work now happens through browser-based PLM and ERP portals rather than locally installed software.
Conclusion
The network perimeter you spent years hardening still matters, but it’s no longer where most of your workforce’s risk actually lives. That risk moved into the browser years ago, and for defense contractors it moved there carrying CUI. Extensions with unreviewed permissions, credential theft that never touches an antivirus signature, shadow SaaS logins nobody inventoried, and patch cadences nobody’s tracking add up to a gap that shows up in assessments and, more urgently, in actual incidents. Closing it doesn’t require ripping out existing tools — it requires treating the browser as the governed, monitored layer it’s become, with the same rigor applied to servers and endpoints for years. Our teams in Boston, Tampa, and Sarasota work with defense contractors on exactly this kind of gap closure, and you can read more about our approach on our About page or browse further coverage in our Insights library.
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.
