StealthTech
A program manager at a machine shop outside Tampa can usually name every laptop, server, and firewall on his network without looking anything up. Ask him how many SaaS applications his 45-person shop is actually connected to, and the number he guesses will be wrong — not by a little, but by a factor of three or four. That gap between what leadership thinks is running and what is actually running is SaaS sprawl, and for a defense contractor holding Controlled Unclassified Information, it is one of the least discussed and most consequential security problems in the building.
SaaS sprawl isn’t a hypothetical. It’s the quoting tool the estimating team signed up for on a free trial two years ago and never cancelled. It’s the file-sharing app an engineer uses because the CAD files are too large for email. It’s the scheduling app HR adopted, the e-signature tool sales picked, and the AI note-taker someone installed on their laptop last quarter without telling anyone. Individually, each one seems harmless. Collectively, they form a security perimeter that nobody drew, nobody inventoried, and nobody is defending — which makes SaaS sprawl security a problem that CMMC assessors, insurers, and threat actors all understand better than most internal IT teams do.
What SaaS Sprawl Actually Looks Like Inside a Defense Contractor
The term sounds abstract until you map it against a real organization. A typical small-to-midsize manufacturer or engineering firm working under a DoD prime contract will have a formally approved stack: an ERP system, Microsoft 365, maybe a PLM tool, a help desk platform, and a handful of line-of-business applications tied to production. That’s the sanctioned list — the one written down somewhere, maybe in a System Security Plan, maybe just in someone’s head.
Then there’s the actual list. Marketing has a graphic design subscription. Finance uses a bill-pay portal that connects to the bank. The quality team adopted a document control app because the built-in one was clunky. Someone in engineering pays for a personal AI tool out of pocket because it makes drafting technical reports faster. None of these tools were vetted for CUI handling, none appear in the compliance documentation, and in many cases, none were ever formally provisioned — they were self-served with a corporate credit card and a free trial.
This is the pattern our team sees repeatedly across manufacturing and engineering clients preparing for CMMC assessments. The sanctioned environment is documented and reasonably well defended. The shadow environment — the SaaS sprawl — is neither.
Why Sprawl Happens Even in Security-Conscious Organizations
Sprawl isn’t a symptom of carelessness. It’s a symptom of speed. Cloud SaaS products are built to remove friction: no procurement cycle, no server to provision, no IT ticket required. An employee with a problem and a credit card can be using a new tool within minutes, and for years that was treated as a productivity win rather than a risk. Departments under deadline pressure will always choose the fastest path to solving their own problem, and asking IT first has never been the fastest path.
Remote and hybrid work accelerated this further. When staff aren’t sitting inside a defined office network, the instinct to route everything through IT-approved channels weakens. A subcontractor coordinating with a prime from a home office in Waltham or a shop floor supervisor pulling up a scheduling app from a tablet in Sarasota is making an in-the-moment tool decision, not a security decision — and that’s precisely the gap sprawl exploits.
Mergers and personnel turnover compound the problem. Acquired companies bring their own SaaS stacks. Departing employees leave behind app subscriptions nobody remembers to audit. New hires inherit login credentials to tools that predate their employment and that nobody ever formally decommissioned. Over a three- or four-year period, this is how a contractor with fifty employees ends up connected to well over a hundred cloud applications, most of which were never reviewed against a security framework.
The CUI Exposure Problem Nobody Is Tracking
For a defense contractor, the real risk isn’t that there are too many apps — it’s that nobody can say with confidence which of those apps have touched Controlled Unclassified Information. CUI doesn’t announce itself. It moves the moment an engineer pastes a spec sheet into a project management tool for context, or a quality manager uploads a drawing with dimensional data into a document review app to get sign-off faster. The people doing this aren’t trying to violate DFARS 252.204-7012 — they usually have no idea the tool they’re using falls outside the CUI boundary defined in their System Security Plan at all.
This is where SaaS sprawl becomes an actual compliance liability instead of just an operational headache. The scope boundary an organization documents for compliance purposes only holds up if the data flow it describes matches the data flow that’s actually happening. Every unsanctioned SaaS application with CUI touching it, even briefly, is an undocumented data flow — and undocumented data flows are exactly what a CMMC assessor is trained to find. The National Archives maintains the CUI registry that defines what qualifies as controlled information in the first place, and the categories are broader than most program managers assume — far broader than “classified drawings,” extending into technical data, export-controlled information, and even certain contract-related correspondence.
The practical consequence is that a contractor can have a technically sound, well-documented security architecture around its sanctioned systems and still fail an assessment because CUI leaked into a tool that was never part of the plan. Sprawl doesn’t just add attack surface. It quietly invalidates the accuracy of the compliance documentation built to describe the environment.
How Sprawl Becomes an Attack Surface
Every SaaS application is an identity relationship, an API connection, a data store, and an administrative console that someone controls — usually not your team. Multiply that by 80 or 150 applications and you have a security perimeter that spans dozens of vendors, each with its own patching cadence, its own breach history, its own third-party integrations, and its own login credentials sitting in an employee’s password manager or, worse, reused from another account entirely.
Threat actors understand this better than most defenders. CISA’s guidance on supply chain and third-party risk reflects a shift in how attackers approach hardened targets: rather than breaching a well-defended primary network directly, they go after the weakest vendor in that network’s orbit. An unsanctioned SaaS tool with minimal security controls, unmonitored login activity, and no multi-factor authentication requirement is a far easier entry point than the ERP system IT actually watches. Once an attacker compromises that smaller application, lateral movement toward the systems that matter becomes a matter of stolen credentials and patience, not a fresh exploit. Our recent piece on MFA fatigue attacks covers a closely related mechanism — attackers don’t need to beat your strongest controls if they can walk in through your weakest one.
Sprawl also multiplies the population of accounts with standing access to sensitive systems. A single-sign-on environment tied to strong identity governance is manageable. A sprawl environment where a dozen SaaS tools each maintain independent logins, independent password policies, and independent session timeouts is not. Every one of those independent logins is a place where a reused password, a phished credential, or an ex-employee’s still-active account can sit unnoticed for months.
Shadow IT and Shadow AI: The Fastest-Growing Category of Sprawl
If sprawl was already a manageable-if-annoying problem two years ago, generative AI tools have made it acute. Employees are pasting proprietary drawings, contract language, and technical specifications into AI assistants to save time, frequently without understanding what happens to that data on the other end. We’ve written previously about how shadow AI use exposes business data in exactly this way — a machinist or engineer trying to solve a problem faster, with no visibility into where the input goes, how long it’s retained, or whether it trains a model that other users might eventually query.
Shadow AI is sprawl in its most concentrated form because the barrier to adoption is nearly zero — a browser tab, no procurement, no IT involvement — and the potential exposure is high, since these tools are frequently fed the exact kind of technical and contract data that CUI protections exist to control. An organization serious about closing this gap needs a documented AI usage policy that draws a clear line between approved tools and prohibited ones, something we outline in more detail in our guide to creating an AI usage policy for employees without grinding productivity to a halt. Properly scoped AI integration work can actually reduce this risk by giving staff a sanctioned, monitored alternative to the tools they’d otherwise adopt on their own.
Getting an Honest Inventory: Where Discovery Actually Starts
You cannot secure what you cannot see, and most organizations dramatically underestimate their SaaS footprint until someone actually goes looking. A real discovery process starts with three overlapping data sources: single sign-on and identity provider logs (which reveal every application an employee has authenticated into using their corporate identity), expense and procurement records (which surface subscriptions paid for outside IT’s normal channels), and network or firewall traffic analysis, which can reveal SaaS connections that bypass SSO entirely.
None of these sources alone tells the full story. SSO logs miss anything an employee signed up for using a personal email and later connected to work. Expense reports miss free-tier tools that never generate an invoice. Traffic analysis misses mobile-only usage on personal devices. A credible inventory triangulates all three, and for most contractors this is the point where the exercise stops being a spreadsheet task and starts requiring the kind of ongoing monitoring infrastructure that a managed IT services partner is built to maintain — not as a one-time audit, but as a standing discipline.
The output of this exercise should be a living application inventory, not a static report. Ownership matters as much as existence: for every application on the list, someone in the organization needs to be named as the accountable owner, responsible for renewal decisions, access reviews, and offboarding. Applications without an owner are, by definition, the ones nobody will notice going stale, getting breached, or quietly accumulating CUI.
Governance That Doesn’t Slow the Business Down
The instinct after discovering sprawl is often to lock everything down, which tends to backfire by pushing adoption further underground. A workable governance model instead separates applications into three tiers: a sanctioned tier with full security review and SSO integration, a conditional tier available for low-risk use cases with documented restrictions on data types, and a prohibited tier explicitly barred from any interaction with CUI or client data.
A short set of ground rules tends to work better than a lengthy policy document nobody reads:
- Every new SaaS application, regardless of cost, requires a lightweight security and data-handling review before procurement, not after.
- Single sign-on is mandatory wherever the vendor supports it, and vendors that don’t support SSO get flagged for extra scrutiny.
- Application ownership is assigned at the time of approval, not discovered after an incident.
- Offboarding checklists include SaaS deprovisioning as a named step, not an afterthought buried under “revoke building access.”
- Quarterly access reviews confirm that accounts still map to active employees with a current business need.
This kind of governance sits naturally alongside the strategic planning work a vCIO already does for growing contractors — deciding what technology the business actually needs is inseparable from deciding what technology it should stop tolerating. Our breakdown of what a vCIO does covers this governance function in more depth for organizations weighing whether they need that role formally in place.
Consolidation, Backup Exposure, and the Overlooked Cost of Sprawl
Every unsanctioned SaaS application that touches business data is also, functionally, an unmanaged data store — one that almost never appears in backup and disaster recovery planning. If a quality team’s document review tool goes down, gets breached, or simply gets deprecated by its vendor with thirty days’ notice, whatever data lived there may not exist anywhere else. Our guide on immutable backups addresses ransomware resilience for sanctioned systems, but that resilience means little if the operative version of a document actually lives in a SaaS tool outside the backup scope entirely. Backup and data recovery planning has to account for the full application inventory, not just the systems IT already knows to protect.
Consolidation is the natural next step once discovery and governance are in place, and it pays for itself twice — once in reduced licensing spend, and again in reduced attack surface. Contractors often discover three or four overlapping tools performing the same function across different departments, each with its own contract, its own admin console, and its own security gaps. A properly scoped cloud transformation engagement can consolidate this into a smaller number of vetted platforms with unified identity management, and even something as specific as replacing a patchwork of personal phone apps and consumer messaging tools with cloud-based VoIP removes an entire category of unmanaged, unmonitored communication tools from the sprawl inventory.
Where This Fits Into the CMMC Picture
CMMC assessors don’t ask “how many SaaS applications do you use.” They ask contractors to demonstrate that CUI is protected everywhere it flows, which means the assessment inevitably surfaces sprawl whether or not the contractor volunteers it. The scoping guidance under NIST SP 800-171 requires organizations to identify every system where CUI is processed, stored, or transmitted — and an accurate scoping exercise is simply impossible without an accurate SaaS inventory underneath it. The DoD CMMC Program itself is built around the premise that self-attestation and third-party assessment both depend on the contractor actually knowing its own environment, and sprawl is the single most common reason that knowledge is incomplete.
The baseline safeguarding requirements under FAR 52.204-21 apply to every system touching federal contract information, sanctioned or not — there’s no carve-out for a tool the finance team adopted without telling anyone. Closing the sprawl gap before an assessment, rather than during one, is consistently the difference between a controlled, well-documented scoping conversation and an assessor uncovering unsanctioned tools mid-review. Contractors in Boston, Tampa, and Sarasota working through certification timelines are better served treating SaaS discovery as a pre-assessment prerequisite, not a nice-to-have.
Conclusion
SaaS sprawl doesn’t get fixed with a single audit or a strongly worded email about approved software. It gets fixed by building discovery, ownership, and governance into how the organization operates day to day — treating every new application the way you’d treat any other system with access to sensitive data, because that’s exactly what it is. The contractors who get ahead of this before an assessment forces the issue tend to find the exercise clarifies far more than their compliance posture; it usually cuts licensing costs, tightens identity management, and removes a long list of tools nobody was using anyway. For a deeper look at how cybersecurity programs are structured around this kind of full-environment visibility, or how co-managed IT support can extend an internal team’s ability to track and govern its own SaaS footprint, our team has spent years helping defense contractors close exactly this gap.
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.
