AI Is Writing Your Code and Leaking Your Secrets

 

I use AI to write code, and I am not giving it up. Neither should your engineering teams. Teams are adopting AI assistance to ship faster, and that shift is not reversing. That is exactly why the security problem underneath it deserves a clear look. AI-assisted development can introduce hardcoded secrets and expand the number, privilege, and reach of the non-human identities working across your delivery pipeline. Most organizations are not governing either one, and that gap is where the next wave of breaches is forming.

None of this argues for slowing down. It argues for governing what AI-assisted development creates, so the speed you gained does not turn into exposure you never priced in.

The risk is not one thing. AI-assisted development expands risk in three connected but distinct places. The generated code can carry security defects. Prompts, repositories, logs, and output can expose credentials, in both directions. And the agents reaching your source control, cloud services, and data need identities with carefully bounded permissions. A secret scanner does not fix an over-permissioned agent, and least privilege does not catch insecure application logic. You have to govern all three.

 

How does AI-assisted development expose secrets?

AI-assisted development exposes secrets because the models reproduce the patterns they learned from, and public code is full of hardcoded credentials. When an assistant generates a working example, it can embed an API key, a connection string, or a token directly in the code, especially when the prompt, the repository context, or the surrounding code already normalizes that pattern. The code runs. The secret can ship.

The data released in 2026 shows how fast this grew in 2025. GitGuardian's State of Secrets Sprawl 2026 counted more than 28 million new hardcoded secrets in public GitHub commits during 2025, a 34 percent jump and the largest single-year rise on record. Leaks tied to AI services rose 81 percent in a single year. In the same analysis, commits co-authored by one popular assistant, Claude Code, exposed secrets at 3.2 percent against a 1.5 percent baseline across all public commits. GitGuardian is careful about that number, and so am I. The leak still runs through a human workflow. Developers decide what to accept, edit, or push. The tool did not fail. The process around it did.

Two forces compound the problem. AI increases code volume and change velocity, which makes manual-only review less reliable as the primary control. And the exposure runs in both directions. An assistant can write a secret into code, and a developer can hand one to the assistant, pasting a production log, a config file, or an error trace full of tokens into a prompt. GitGuardian found that roughly 28 percent of secret incidents now originate outside code repositories entirely, in places like Slack, Jira, and Confluence, where credentials get shared during urgent troubleshooting. Any policy that governs only the code misses half the problem.

None of that is a reason to stop. It is a reason to assume AI-assisted work may contain secrets until a scan proves otherwise, and to govern both what the tools can reach and what people can submit.

Every AI coding agent needs a governed identity

Here is the part that sits squarely in my field. AI-assisted development is not only a code problem. It is an identity problem.

Every AI agent that reaches your environment does so through one or more non-human identities: a service account, an OAuth client, an API key, a certificate, or a short-lived token. A coding assistant, a build agent, a deployment bot, each authenticates as something, and the more work you hand it, the more entitlements it accumulates. In agentic and multi-agent workflows, one orchestrator can create or delegate to additional agents, multiplying credentials and audit paths as it goes.

 

This is not a fringe concern. Reports through 2026 put non-human identities at anywhere from around fifty to one hundred times the number of human identities in cloud-heavy environments, with the exact ratio depending on what gets counted. The World Economic Forum has called non-human identities the new frontier of agentic AI risk, and analysts increasingly treat AI agents as a distinct identity type that is neither fully human nor fully machine. I covered the governance side in Non-Human Identities and AI Agents: The New Blind Spot in Your IAM Program, and AI-assisted development is where that blind spot turns operational.

The risk is not limited to the code an assistant suggests. Once an agent can read a repository, call tools, open tickets, invoke CI/CD, or connect through a Model Context Protocol server, it becomes an execution path into the enterprise. GitGuardian found more than 24,000 secrets sitting in Model Context Protocol configuration files on public GitHub, a pattern the setup instructions themselves often encourage. Add prompt injection delivered through a README, an issue, or a dependency's documentation, and the agent's permissions, allowed tools, and data boundaries need the same design discipline you give any privileged workload.

The uncomfortable pairing is this. AI writes code that leaks the very secrets these identities depend on, inside a system where the identities themselves are barely governed. Leaked credential, meet ungoverned identity. That is the attack path.

The productivity is real, so protect it

I want to be direct about where I stand, because the headline can read the wrong way. I am not arguing against AI-assisted development. I am arguing for keeping it.

The teams shipping with AI assistance are faster, and that advantage is not going back in the box. Telling engineers to slow down is both futile and wrong. The organizations that win will adopt aggressively and govern deliberately, and those two things are not in tension. Security is not the brake on AI development. It is what lets you keep your foot on the accelerator without wrapping the car around a tree.

Consider how a mature enterprise already treats any third-party dependency. You do not refuse open-source libraries because some carry vulnerabilities. You scan them, track them, patch them, and keep shipping. AI-generated code deserves the same posture. Treat it as untrusted input from a very fast contributor, verify it, and move on. That is not skepticism about AI. It is how you make AI safe to rely on at scale.

How do you secure AI-assisted development without slowing it down?

You secure it by governing the two things AI development produces, code and identities, with controls that run at machine speed instead of human speed. The goal is not more meetings. It is automation that keeps pace with the tools creating the risk.

A practical program rests on a few moves:

• Scan for secrets continuously, in the pipeline and beyond it. Run detection on every commit and every AI-assisted change, and extend it to the tickets, chat, and logs where secrets also land. Removing a key from code is not enough, since it can be recovered from history, so rotate or revoke it too.
• Give every agent its own scoped identity. No shared keys, no borrowed service accounts, outside narrow legacy exceptions you document and monitor. Each agent gets a named identity with least-privilege access to only what its task requires.
• Prefer short-lived, dynamically issued credentials. Replace long-lived static keys with tokens that expire in minutes where the platform supports it. A leaked credential that has already expired is close to a non-event.
• Keep an owned inventory of non-human identities. Every agent and service account needs a human owner, a documented purpose, and a decommission date. Unowned identities are where risk hides.
• Treat AI output as an untrusted contribution, and do not stop at review. Apply the same supply-chain controls you use elsewhere: dependency and infrastructure-as-code scanning, branch protections, code-owner review for anything touching authentication, authorization, cryptography, payments, data access, or deployment, and an audit trail that ties each material change to a user, an agent, and an identity.

These controls shift the security work from a late, manual gate to an early, automated one, which is the only model that survives contact with AI-speed development. Integrated into developer workflows, they cut late-stage rework instead of adding a release bottleneck, and they keep most of AI's delivery advantage while slashing the cost of remediation.

Detection without revocation is not remediation, and the data proves it. GitGuardian retested credentials it first confirmed valid in 2022 and still found more than 64 percent of them live in 2026. When a secret surfaces, rotate or revoke it, trace where it was used, assess what it could reach, and fix the control at the point it entered the workflow.

Where you sit on this path matters more than doing everything at once:

Stage	Minimum standard
Pilot	Approved tool list, no production secrets in prompts, user-level attribution, basic secret scanning
Team rollout	SSO and SCIM, repository and data-access boundaries, CI secret scanning, branch protections, named owners for service accounts
Enterprise scale	Short-lived federated workload identity, centralized secrets management, agent and tool allowlists, full audit logging, revocation workflows, continuous entitlement review

This is also where the commercial conversation lives, and it is rarely a technical failure that stalls these programs. It is that the person who sees the risk cannot translate it into a consequence the budget holder acts on. I worked through that exact dynamic in Why Identity Risk Loses the Budget Conversation, and it applies directly here. Frame AI governance as protecting the productivity leadership already values, and you get funded. Frame it as a brake, and you do not.

I write about where identity security and commercial strategy meet, because in AI-assisted development they are the same conversation. If your organization is working through this, connect with me on LinkedIn.

Frequently asked questions

Is AI-generated code less secure than human-written code?

Not inherently, but it should not be presumed secure. Results vary by model, prompt, language, task, and review process. A 2026 study across six leading models reported confirmed vulnerabilities in about a quarter of generated samples, while earlier research on one popular assistant found security weaknesses in roughly 40 percent of the scenarios tested. Those figures need their methodology to mean anything, and they do not add up to a universal defect rate. The operational answer is to test and review AI output under the same controls, or stronger ones, that you apply to any untrusted contribution.

What is a non-human identity in AI development?

It is the identity assigned to software, a workload, a service, a bot, a pipeline, or an AI agent, so it can authenticate and act without an interactive human login. Its authenticator might be a service account, a workload identity, an OAuth client, a certificate, an API key, or a short-lived token. The governance questions that matter are who owns it, what it can access, how long it lasts, how its activity is logged, and how it gets revoked.

Can developers paste production code or error logs into a coding assistant?

Only if your organization has approved the tool, understands its data-handling terms, and has defined what may be submitted. Production secrets, customer data, private keys, and regulated information should be blocked or redacted before they reach a prompt. The same policy should cover repository-context features and tool integrations, not just the chat box.

What should happen when a secret shows up in AI-assisted code?

Treat it as an incident, not a text edit. Revoke or rotate the credential, determine whether it was used, assess the access it carried, remove it from active code and configuration, and add or tune the control that should have caught it before production.

How do we let developers use AI without creating security debt?

Automate the controls so they run at the speed of the tools. Scan every change and channel for secrets, scope each agent to least privilege, expire credentials quickly, and review AI output like any third-party dependency. That keeps the productivity while closing the exposure.

The speed is worth keeping

AI-assisted development is one of the most significant productivity shifts enterprise engineering has seen, and the organizations leaning into it are right to. The mistake is treating the speed as free. It arrives with generated code that needs verifying, secrets that need detecting and rotating, and machine identities that need scoping, ownership, and observation, and the companies that build those habits early will keep their advantage while others clean up breaches they could have prevented.

AI is writing your code, and yes, it can leak your secrets. That is a solvable problem, and solving it does not mean making developers wait. Make secure behavior the default: credentials injected at runtime instead of written into code, short-lived access instead of permanent keys, and automated checks that catch problems before production. Govern the identities, protect the context, scan the code and the secrets, and let your teams keep building at the speed the tools finally made possible.

---

Navneet Lounsberry writes on cybersecurity compliance and commercial strategy, most recently with Idenhaus Consulting. She spent more than two decades in enterprise technology sales and business development across IBM, SAP, Manhattan Associates, and UKG.

 

Copyright © 2026, Full Throttle Media, Inc. FTM #fullthrottlemedia #inthespread #sethhorne

How to Measure AI Search Traffic in 2026

 

You put in the work to get cited by AI. You structured your content for extraction, answered the questions buyers actually ask, and started showing up in ChatGPT and Google's AI Overviews. Then you open Google Analytics, filter for those sources, and find a dozen sessions. The natural conclusion is that the channel is too small to matter.

That conclusion is probably wrong, but not for the reason you might guess. AI search traffic is not one clean channel you can read off a single report. AI-driven demand is usually larger than the AI referrals visible in analytics, yet no report can say how much larger. Some clicks keep an AI referrer and can be measured. Others lose their source, or influence a visit that returns days later through Direct or branded search. The problem is not that all AI traffic is hidden. It is that AI influence is scattered across several reporting buckets, and most teams try to read it as one number.

This is the measurement gap left open by the shift to answer engines. If you have already worked through how SEO, AEO, and GEO function as one connected strategy, this is the reporting problem sitting underneath all three. Getting cited is half the job. Measuring it honestly is the other half, and most teams miss in one of two directions: ignoring the channel, or crediting it for everything they cannot otherwise explain.

 

Three things people lump together as AI search traffic

Before you measure anything, separate three ideas that are not the same:

• AI-referred traffic is a session that arrives with an identifiable AI source, such as a referral from chatgpt.com.
• AI-influenced traffic is a buyer who met your brand inside an AI answer, then returned later through Direct, branded search, email, or a bookmark.
• AI visibility is an appearance or citation in an AI answer that may create awareness without ever producing a click.

These do not add into one precise figure, and pretending otherwise is where most AI reporting goes wrong. Report them as separate signals, not a single invented total.

Why can AI-influenced visits appear as Direct traffic?

Some AI-driven visits arrive without a usable referrer and land in Direct, most often in app and in-app-browser flows where the referrer is stripped or never passed. But Direct is not an AI bucket. In GA4, Direct means the session had no clear referral source, which also covers typed URLs, bookmarks, untagged campaign links, redirects, and privacy or consent signal loss.

That distinction cuts both ways. Assume none of your Direct traffic is AI and you undercount the channel. Assume all of it is AI and you fool yourself with a number you cannot defend. Direct is an attribution gap to investigate, not a proxy for ChatGPT.

Google's own AI surfaces sit in a different blind spot. GA4 still cannot reliably isolate AI Overview and AI Mode sessions as their own acquisition source, because the click passes through a google.com URL and reads as ordinary organic. As of 2026, though, that is no longer the whole story, and the fix lives in a different tool.

Is AI search traffic worth measuring if it is only 1% of visits?

Yes, because the value per visit can be far higher than its share of volume. Visible AI referrals are small today. Conductor's benchmark of 13,770 domains put them at 1.08 percent of total traffic on average, and that is visible referrals, not all AI influence.

Several case studies suggest that small slice punches above its weight. Semrush's study, We Studied the Impact of AI Search on SEO Traffic, found the average AI search visitor from a non-Google source such as ChatGPT was 4.4 times as valuable as a traditional organic visit, measured by conversion rate. Ahrefs, analyzing its own site, reported AI search at 0.5 percent of traffic but 12.1 percent of signups. Seer Interactive, looking at a single client, measured ChatGPT referrals converting at 15.9 percent against 1.76 percent for Google organic.

Read those as signals, not laws. They come from different businesses, funnel stages, and definitions of a conversion, and at least one analysis found no significant difference at all. The thread that holds is intent: a buyer who clicks through from an AI answer has often had the category summarized and the options shortlisted already, so the click lands closer to a decision. That makes AI referrals disproportionately valuable in some high-consideration and B2B journeys. Whether they beat your paid, email, or branded-search cohorts is something only your own numbers can settle, on one conversion definition.

How do you measure AI search traffic?

You measure it as a system of partial views, because no single report captures the whole thing. Four layers cover most of what you need.

Isolate the AI referrals you can see

In GA4, build a custom channel group rather than editing the default, and classify by session source or session source and medium. A few specifics decide whether it works:

• Group known AI domains such as chatgpt.com, perplexity.ai, claude.ai, gemini.google.com, and the Copilot domains, and confirm them against your own raw source data rather than copying a generic list.
• Place the AI rule above generic Referral in the channel-group priority, or Referral will swallow it first.
• Report outcomes, not just sessions: engaged sessions, key events, qualified leads, and pipeline, plus the landing pages those referrals hit.

Before you declare a large hidden-AI problem, rule out the ordinary causes of inflated Direct first: confirm GA4 fires once, audit cross-domain and consent setup, and tag your own campaign links. A clean attribution baseline is what makes the AI signal trustworthy.

Use Search Console for Google's AI surfaces

Google Search needs its own lane. On June 3, 2026, Google launched a dedicated Generative AI performance report in Search Console that separates impressions in AI Overviews and AI Mode from standard organic results, broken out by page, country, and device. It answers a question GA4 cannot: whether your URLs actually appear in Google's AI answers.

Read it for what it is. The report shows impressions only, no clicks or conversions, and is rolling out to a subset of properties. It also covers Google Search alone, so it says nothing about ChatGPT, Perplexity, or Claude. Use it as a visibility gauge, then turn to GA4 and CRM data for impact. An impression report is not a revenue report.

Ask buyers what analytics cannot see

Self-reported attribution reaches the influence your tools miss by design, including zero-click and cross-device paths. Split discovery from evaluation: ask where someone first heard of you, then, separately, what they used to evaluate you. A buyer may first meet you in Google, compare vendors in ChatGPT, and convert through branded search, and one forced-choice field erases that path. Self-report depends on memory, so treat it as one of the few ways to catch delayed AI influence, not as proof.

Track citation share as a leading indicator

Citation is the earliest signal, moving before traffic and revenue do. Define it plainly: citation share is the portion of your tracked prompts in which your brand or domain appears. Send the questions your buyers ask to the major models on a schedule and watch the trend against competitors. The caveat is real: results depend on the prompt set, the model version, location, and the tool sampling them, so read citation share as a directional indicator, not a promise of pipeline.

Run the four together and you get triangulation instead of a false total. Referral data shows a conservative floor, Search Console shows Google AI visibility, self-report fills the invisible middle, and citation share tells you where things are heading.

When should you evaluate AI-search ROI?

Set expectations as a cadence, not a countdown. There is no universal timeline, because indexing, sales-cycle length, content maturity, and model updates all move it. What holds up is a review rhythm.

Document a baseline now: citation visibility, identifiable AI referrals, the landing pages involved, conversions, and branded-search demand. Check source and landing-page trends monthly, and assess qualified pipeline and revenue quarterly, which matters most for longer sales cycles. For planning, many teams read early citation and traffic movement at 60 to 90 days and judge pipeline at 3 to 6 months, but treat those as observation points, not guarantees.

This is the same patience the systems demand elsewhere, and it connects to why AI content rankings settle only after an early climb. The models take time to trust a source. Your reporting has to give them that time before you call the outcome.

Frequently asked questions

Why is my ChatGPT traffic showing as Direct in Google Analytics?

A ChatGPT visit can land in Direct when the click reaches your site without a usable referrer, which is common in app flows. But Direct is not an AI-only bucket. GA4 defines it as traffic with no clear referral source, so it also holds bookmarks, typed URLs, untagged links, and sessions where privacy or redirect issues stripped the source. Treat Direct as an attribution gap to investigate, not a stand-in for AI traffic.

Can you track traffic from Google AI Overviews and AI Mode?

Not cleanly in GA4, where those clicks read as ordinary Google organic. Since June 3, 2026, Search Console has a dedicated Generative AI report that shows how often your URLs appear in AI Overviews and AI Mode. It measures impressions only, with no clicks or conversions, and covers Google Search alone. Use it for visibility, then use GA4 and CRM data for business impact.

Does AI search traffic convert better than organic search?

Often, especially in high-consideration journeys, but it is not a universal rule. Ahrefs reported AI search at 0.5 percent of its traffic and 12.1 percent of signups, and Seer Interactive reported far higher ChatGPT conversion than Google organic for one client. Compare AI referrals against your own organic, paid, email, and branded-search cohorts using one conversion definition before you conclude anything.

What tools measure AI search visibility?

Search Console covers Google's AI surfaces. For ChatGPT, Perplexity, and others, citation trackers such as Profound, Peec AI, and Semrush's AI visibility features record how often you appear across prompts. Pair any of them with GA4 and a self-reported lead-source field, since no single tool captures the whole channel.

How much of my traffic should come from AI search?

There is no universal target. Conductor put visible AI referrals at 1.08 percent of traffic across 13,770 domains, and that is visible referrals, not total AI influence. Set goals around outcomes instead: citation coverage for your priority questions, the conversion rate of identifiable AI referrals, and AI-influenced leads and revenue.

Measure the channel as a system, not a line item

The teams losing ground in AI search are rarely the ones getting cited least. Often they are getting cited and never know it, because their analytics filed the evidence under Direct. The opposite error costs just as much: crediting the channel for every unexplained visit and building a story you cannot defend. Both come from treating AI search as a single number.

It is not one. AI-driven demand is fragmented across visible referrals, Google AI visibility, delayed brand searches, self-reported discovery, and CRM outcomes. Measure each on its own terms, clear the ordinary attribution problems first, and give revenue the months it needs to surface. Do that, and a channel that looked like noise becomes one you can defend in a budget meeting and grow on purpose.

Getting found by AI is the work of the last two years. Measuring it honestly, and improving it, is the work of the next one.

 

Copyright © 2026, Full Throttle Media, Inc. FTM #fullthrottlemedia #inthespread #sethhorne

CMMC Phase 2 Paused: Why the Work Should Not Stop

On July 13, 2026, the Department of Defense suspended Phase 2 of the Cybersecurity Maturity Model Certification (CMMC) program and opened a 60-day review. Within hours I heard the same reaction across the defense industrial base: good, now we can slow down.

That reading is wrong, and it will cost the contractors who believe it. The Department paused one mechanism. It did not lift a single security obligation. If your contracts require you to protect controlled unclassified information, your legal duties today look exactly as they did on July 12.

Here is what actually changed, what did not, and why the contractors who keep moving will hold the advantage when the assessors return.

What did DoD actually suspend?

DoD suspended Phase 2 of the CMMC rollout, the stage that would have required many contractors handling CUI to pass a third-party assessment as a condition of award. That requirement was scheduled to take effect on November 10, 2026. A new CMMC Reform Task Force, reporting to the DoD Chief Information Officer, now runs a review of the program, with contractor input collected through a request for information due August 14, 2026.

Two distinctions matter here. First, the suspension targets Phase 2 of the rollout, not CMMC Level 2 itself. Level 2 remains the security tier that applies to most contractors who handle CUI. Second, Phase 1 self-assessment requirements stay fully in place. The Department kept the self-attestation layer running and removed only the outside audit.

Is CMMC cancelled?

No. The Department paused a verification step. It did not repeal a rule. The CMMC Program rule at 32 CFR Part 170 and the DFARS acquisition clauses remain on the books, and unwinding either one would take formal rulemaking measured in months. Officials have not ruled out larger changes, but nothing in the July memo removes an existing requirement.

Treat CMMC as the checking mechanism, not the standard. The standard came first, and it still governs your program.

What has not changed for defense contractors

This is the part the headlines miss. Several obligations survived the suspension untouched.

• DFARS 252.204-7012 still applies. This clause has required contractors and subcontractors that handle covered defense information to implement the 110 controls of NIST SP 800-171 since 2017, and to report cyber incidents within 72 hours.
• Your NIST SP 800-171 self-assessment still counts. You calculate a score against the 110 requirements and keep it current.
• Your SPRS score is still live. Every prime and contracting officer you work with can see it, and it factors into your eligibility for award.

Enforcement did not pause either. The Defense Industrial Base Cybersecurity Assessment Center (DIBCAC) continues to run reviews, and the Department of Justice continues to pursue False Claims Act cases tied to inaccurate cybersecurity attestations. With no third-party assessor checking your work first, an overstated SPRS score now carries more personal exposure, not less.

Contractors that serve both defense and civilian agencies get no reprieve at all. The duty to protect sensitive federal information reaches beyond CMMC, so a pause on one program does not clear the wider requirement.

Why pausing your compliance program is a commercial mistake

I spent two decades selling enterprise technology, and I learned early that timing beats intensity. The contractors who treat this pause as schedule relief rather than permission to stop will convert it into a market position.

Look at the math behind the assessment bottleneck. More than 100,000 companies in the defense industrial base need an assessment, and roughly 100 authorized third-party assessor organizations exist to perform them. A 60-day review does not close a gap that wide. When the requirement returns, and the underlying rule suggests it will in some form, the queue will favor the companies that stayed ready.

There is a business development angle that compliance teams sometimes overlook. Primes vet their subcontractors on cyber posture before they award work. A current, defensible SPRS score is a sales asset. It signals that you can hold CUI without becoming the weak link in a bid. Let that score go stale during the pause, and you hand a competitor a reason to take the flow-down.

I write about this intersection of cybersecurity compliance and commercial strategy because the two decisions are rarely separate. If this is the conversation you are having inside your own organization, connect with me on LinkedIn.

What defense contractors should do now

The right response to a pause is steady progress, not a full stop. A practical posture for the review period looks like this.

• Keep your evidence current. Configuration records, scan results, and POA&M updates you collect now will count under any assessment model the task force designs.
• Refresh your SPRS score. A stale score is a contract risk today, suspension or not.
• Close your open POA&M items on the original timeline. Remediation you schedule now lands well before assessors return.
• Confirm your CUI boundary. Know which systems touch covered defense information, and keep that scope documented.
• Watch for a class deviation or a DFARS amendment. A memo changes discretion. Only a rule change moves the law, so track the formal record rather than the headlines.

This is the operational discipline I described in CMMC in the Plant, Not the PowerPoint, where compliance lives on the shop floor instead of in a slide deck. The pause does not change that. It rewards the companies that already built the habit.

Frequently asked questions

Is CMMC going away?

No. The Department suspended Phase 2 of the rollout and launched a review. The CMMC Program rule and the DFARS clauses remain in effect, and removing them would require formal rulemaking.

Do I still need to meet NIST SP 800-171 during the pause?

Yes. If your contract includes DFARS 252.204-7012 and you handle covered defense information, you still implement all 110 controls of NIST SP 800-171 and maintain your System Security Plan.

Do I still have to post an SPRS score?

Yes. Self-assessment and SPRS score posting remain mandatory. Your score stays visible to primes and contracting officers throughout the review.

When will CMMC Phase 2 resume?

No firm date exists. The task force review runs on a 60-day clock, and the Department has not committed to a restart date. Plan for the requirement to return rather than disappear.

Can enforcement still happen while Phase 2 is paused?

Yes. DIBCAC reviews and False Claims Act enforcement continue. An inaccurate self-attested score carries real legal exposure with no third-party assessor in the loop.

The bottom line

The CMMC Phase 2 pause is a shift in schedule, not a change in what the government expects you to protect. The rule stands, the DFARS clauses stand, and your self-assessment still speaks for you every time a prime checks your posture. Contractors who read the memo as a stop sign will lose ground to the ones who read it correctly, as time to get further ahead.

Use the window. Keep your controls live, keep your score honest, and keep your program moving. When the assessors come back, and the structure of the program suggests they will, readiness will separate the companies that win defense work from the ones still explaining why they waited.

---

Navneet Lounsberry writes on cybersecurity compliance and commercial strategy, most recently with Idenhaus Consulting. She spent more than twenty years in enterprise technology sales and business development with IBM, SAP, and others.

 

Copyright © 2026, Full Throttle Media, Inc. FTM #fullthrottlemedia #inthespread #sethhorne

Why Identity Risk Loses the Budget Conversation

 

By Navneet Lounsberry

---

 

In May 2026, Verizon published the nineteenth edition of its Data Breach Investigations Report. For the first time in the report's history, stolen credentials lost the top spot as the leading initial access vector. Vulnerability exploitation climbed to 31 percent. Credential abuse dropped to 13 percent, down from 22 percent the year before.

I watched that finding travel through the market in about a week. Vendors repositioned. Analysts wrote it up. And somewhere in a budget review, a finance leader pulled up the headline and asked a reasonable question: if identity attacks are falling, why does the identity program need more money this year?

The security team in that room knows the answer. Verizon tracked credential abuse across the full breach chain, not just the front door, and found it present in 39 percent of breaches. The report also introduced a new pretexting category that absorbed some of what previously counted as credential abuse. The headline describes first contact. The 39 percent describes what attackers actually do once they arrive.

Knowing that answer and delivering it are two different skills. Most security teams have the first one. Fewer have the second. That gap explains more stalled identity programs than any technical shortcoming I have seen across twenty years of enterprise selling.

Why does identity security lose the budget conversation?

Identity security loses budget conversations because practitioners describe risk in architectural terms while executives allocate money in consequence terms. The technical description is correct. It simply does not answer the question the person holding the budget is actually asking.

A security architect says the organization runs password hash synchronization with a single Entra Connect server that sits outside the Tier 0 management boundary. Every word of that carries meaning. None of it tells a CFO what breaks, what it costs, or what happens if the company does nothing for another year.

This is not a communication failure in the soft sense. It is a translation failure with a measurable price. Programs that never get funded never reduce risk, and the exposure compounds quietly while the architecture documentation gets more accurate every quarter.

The identity bridge shows the problem clearly

The clearest example I know sits in almost every large hybrid environment: the connection between on-premises Active Directory and Microsoft Entra ID.

What is the identity bridge?

The identity bridge refers to the components that link on-premises identity to cloud identity. In most Microsoft environments that means Entra Connect synchronization servers, pass-through authentication agents, and Active Directory Federation Services where organizations still run federation.

Microsoft does not treat these components casually. Its own documentation classifies Entra Connect servers, AD FS, Entra application proxy, and Active Directory Certificate Services as Control Plane assets, the tier formerly called Tier 0, alongside domain controllers themselves. Microsoft recommends restricting administrative access to these servers to tightly controlled groups, denying NTLM authentication to the Entra Connect server, and hardening the platform to the same standard applied to the directory it serves.

The reasoning is direct. Entra Connect holds privileged access to both sides. It reads objects from Active Directory using a connector account and writes synchronized objects into Entra ID using a dedicated service account. In password hash synchronization deployments it reads Kerberos hash material from the directory. Anyone who controls that server controls the credentials of every synchronized account.

Why do attackers target the identity bridge?

Attackers target the bridge because compromising it converts a local foothold into complete access across both environments, and because the resulting access looks legitimate.

Golden SAML illustrates this better than any other technique. CyberArk Labs first described the attack in 2017. An attacker who obtains the private key of an AD FS token-signing certificate can forge authentication assertions for any user, in any role, against any application that trusts that federation service. The forged token validates correctly against the public key. Multifactor authentication does not apply, because no authentication actually occurs. Conditional Access policies do not apply for the same reason. The relying party cannot readily distinguish the forged assertion from a genuine one.

This is not theoretical. The threat actor behind the SolarWinds intrusion used exactly this technique in the wild, compromising SAML signing certificates and minting valid tokens to reach hosted resources including email. Mandiant documented the technique in further detail in 2021, and its researchers recently found that manual certificate rotation can silently leave active signing keys recoverable from Machine DPAPI, meaning organizations that believed they had rotated remained exposed.

Read that sequence carefully. An attacker who reaches one server bypasses every identity control the organization purchased, and does it in a way that generates authentic-looking activity.

Why does the bridge stay underfunded?

Here is where the commercial problem shows up. The technical case for protecting the identity bridge is overwhelming and publicly documented by the vendor itself. The work still does not get funded, for four reasons that have nothing to do with architecture.

• Nobody senior owns it. The sync server usually belongs to a Windows infrastructure team that reports through IT operations, not security. It sits between two org charts and appears fully in neither.
• No compliance framework names it. Auditors ask about MFA, access reviews, and privileged accounts. Few ask whether the synchronization server carries a Control Plane hardening standard, so the finding never appears on the remediation list that drives spending.
• It never fails loudly. A misconfigured firewall causes an outage. An underprotected sync server runs perfectly for years, right up until it does not.
• It has no business name. Executives fund things they can name. "Entra Connect hardening" is not something a board member can repeat to a peer.

That last point matters most. Budget follows narrative, and the identity bridge arrives without one.

How do you translate identity risk into business language?

Translation is a discipline, not a personality trait. Three moves do most of the work.

Name the consequence, not the mechanism

Executives do not need to understand token forgery. They need to understand what an attacker gains and what the organization loses.

Compare two descriptions of the same risk. The first: an attacker with administrative access to the AD FS server can extract the token-signing certificate and forge SAML assertions that bypass Conditional Access. The second: one compromised server lets an attacker log in as our CFO, from anywhere, without a password, and our multifactor investment does not stop it.

Both statements are true. Only one of them ends with someone asking what it would take to fix.

I want to be precise about what this is not. Translation does not mean simplifying until the claim stops being accurate, and it does not mean reaching for fear. Buyers eventually catch overstated risk, and the credibility loss outlasts the deal by years. The goal is to state the real consequence in the vocabulary of the person deciding.

Attach the risk to something leadership already funds

Unnamed risk competes badly. Risk attached to a funded priority competes well.

Nearly every enterprise currently runs a cloud migration, an ERP program, a merger integration, or a compliance deadline with executive attention behind it. The identity bridge sits underneath all of them. A migration that synchronizes identities into a cloud tenant depends entirely on the integrity of that synchronization. A defense contractor working toward CMMC assessment cannot demonstrate access control over systems where a single server undermines every access decision.

Framing the work as protecting an initiative the organization already committed to does something a standalone security request cannot. It moves the conversation from new spending to protecting existing spending, and those two conversations have very different success rates. I wrote about a related version of this dynamic in CMMC in the Plant, Not the PowerPoint, where compliance programs succeed or fail based on whether they touch operational reality.

Offer the smallest credible first step

Large identity programs stall because they ask for a decision proportional to their scope. Executives approve things they can reverse.

A hardening assessment of three servers is a decision someone can make in a single meeting. A three-year identity governance transformation requires a steering committee, a business case, and a budget cycle. The first one creates evidence that makes the second one easier to approve later.

This sequencing is not a sales technique. It reflects how organizations genuinely absorb change, and practitioners who understand it get more of their work funded than practitioners who insist on the complete program up front.

What buyers actually say when identity risk stalls

Certain objections repeat across industries. Each one signals a specific gap.

When a buyer says they already deployed MFA, they believe they solved the identity problem. They have not heard that token forgery and session theft operate downstream of authentication entirely.

When a buyer says they cannot explain this to their board, they are asking for language, not information. That request deserves a direct answer rather than more technical detail.

When a buyer says the sync server belongs to another team, they have identified an ownership gap that will block the work regardless of how strong the technical case becomes. Somebody has to resolve that before anything else moves.

When a buyer says nothing has happened yet, they are applying the reasonable heuristic that quiet systems are healthy systems. The identity bridge is specifically the place where that heuristic fails, and saying so plainly tends to land.

What this means for commercial teams in cybersecurity

I have spent my career on the commercial side of enterprise technology, at IBM, SAP, Manhattan Associates, UKG, and most recently in identity and access management consulting. The pattern I keep returning to is this: technical depth and commercial effectiveness are not competing skills, and the strongest people in identity security refuse to choose between them.

The sellers who consistently win complex identity deals do not win because they know more about Kerberos than their competitors. They win because they can hold an architecture conversation with a security engineer at nine in the morning and a consequence conversation with a CFO at two in the afternoon, without changing the underlying facts between those two meetings.

That second conversation is where most identity programs live or die, and it receives a fraction of the preparation the first one gets. For anyone building a career in this market, the translation skill compounds faster than any product certification.

That translation skill sits alongside the rest of the commercial toolkit. Full Throttle Media covers the adjacent territory in B2B Displacement Campaigns: Win Competitor Customers, which works the same problem from the account strategy side.

Frequently asked questions

Is the identity bridge only a Microsoft problem?

No. Microsoft environments make it most visible because Entra Connect and AD FS are widely deployed and well documented. Any organization that synchronizes or federates identity between an on-premises directory and a cloud provider carries the same structural exposure, including those running third-party identity providers alongside a legacy directory.

Does multifactor authentication protect against Golden SAML?

No. Golden SAML forges the authentication assertion itself, so the authentication event never occurs in a form that MFA or Conditional Access can evaluate. Protecting against it requires securing the federation infrastructure, controlling and monitoring token-signing certificates, and auditing certificate export and configuration changes.

How should an organization prioritize the identity bridge against other security work?

Prioritize it by blast radius rather than by likelihood. Most security findings expose one system. A compromised synchronization or federation server exposes every synchronized identity across both environments simultaneously, which places it in the same category as a domain controller.

What is the first question a security leader should ask about hybrid identity?

Ask who administers the synchronization and federation servers, and whether those administrators use the same accounts and workstations they use for ordinary IT work. The answer reveals whether the organization treats the bridge as a Control Plane asset in practice or only in documentation.

Did identity risk actually decline in 2026?

The 2026 Verizon DBIR showed credential abuse falling as an initial access vector, partly because a new pretexting category absorbed some incidents previously counted as credential abuse. Across the full breach chain, credential abuse still appeared in 39 percent of breaches. Attackers changed how they get in more than they changed what they do afterward.

The work is a translation problem

The identity bridge deserves attention on its technical merits, and the vendor documentation, the threat research, and the incident history all say so clearly. None of that has been enough on its own, which tells us something worth taking seriously.

Security programs do not fail only because teams miss the risk. They fail because the people who see the risk most clearly describe it in a language the people holding the budget do not speak. That is a solvable problem, and solving it does not require anyone to dilute the technical truth. It requires naming consequences, attaching risk to priorities the organization already values, and asking for a first step small enough to approve.

 

---

About the Author

Navneet Lounsberry brings over two decades of enterprise sales and business development experience across IBM, SAP, Manhattan Associates, UKG, and Idenhaus Consulting, where her work spanned identity and access management and cybersecurity compliance, including CMMC. A Georgia Tech graduate, she writes about how enterprise buyers in regulated industries actually evaluate, procure, and operate compliance programs.

 

 

Copyright © 2026, Full Throttle Media, Inc. FTM #fullthrottlemedia #inthespread #sethhorne

CMMC in the Plant, Not the PowerPoint: Finding CUI Where Manufacturers Least Expect It

 

By Navneet Lounsberry

---

A tier-two precision machine shop with 80 employees and an aerospace prime customer sits down for a pre-assessment scope review. Leadership is confident. Controlled Unclassified Information (CUI) lives on the engineering file server, access is restricted to five engineers, email runs through a GCC High tenant. The team believes it is ready.

The assessor walks the floor. Within an hour, CUI has been found on a shared tablet at a first-article inspection station, on two CNC human-machine interface (HMI) screens displaying PDF drawings, in a print spool queue on an unmanaged network printer, in the scheduler's email inbox where traveler sheets quote controlled dimensions verbatim, and on a USB drive in a machinist's toolbox. Scope expands from 12 workstations to more than 60 devices. The assessment is pushed back six months while remediation catches up. The budget triples.

This scenario is a composite drawn from patterns I have watched recur across defense manufacturing environments, not a single client. It is what Certified Third-Party Assessor Organizations (C3PAOs) report seeing over and over. C3PAOs are required to validate CUI asset identification independently, not to accept engineering's initial scope at face value, which is why the plant walk carries the weight it does. The underlying issue is not a defensive posture problem. It is a scoping problem, and it is solvable. The catch is that scoping has to be addressed before the plant walk, not during it.

Why CMMC Scoping Is the Whole Game for Manufacturers

Phase 2 of the Cybersecurity Maturity Model Certification (CMMC) rollout begins November 10, 2026. Starting on that date, third-party C3PAO Level 2 assessments are expected to be required in most new Department of Defense contracts involving CUI, driven by the applicable DFARS clauses and individual solicitations. This is no longer a future planning exercise. Prime contractors including Lockheed Martin, Boeing, RTX, General Dynamics, and BAE Systems are already issuing supplier notices, portal-based questionnaires, and flow-down packages. The pressure reaching tier-two and tier-three manufacturers is coming from the top of the supply chain, not from the DoD directly.

Assessor capacity is the compounding factor. Industry estimates place the number of Certified CMMC Assessors in the hundreds against an affected contractor base of roughly 300,000, with reported C3PAO backlogs of six to twelve months. A failed or delayed assessment does not just generate remediation costs. It pushes an organization back into a queue that is only growing.

Scope determines the economics of certification. Published case data on a 40-person defense manufacturer documents total first-year investment dropping from roughly $140,000 under an enterprise-wide approach to about $78,000 when scope was architected through a properly segmented enclave, a 45 percent reduction on identical compliance obligations. C3PAO assessment fees alone range from approximately $15,000 for a tightly scoped enclave to more than $100,000 for a sprawling full-organization boundary.

Here is the trap most manufacturers walk into: overscoping and underscoping both fail, for different reasons. Overscoping commits the organization to implementing all 110 NIST SP 800-171 Rev. 2 controls (currently incorporated by reference in 32 CFR 170 as the CMMC Level 2 control baseline, despite being superseded by Rev. 3 in the NIST publication series) across systems that never needed them, inflating cost and stretching the timeline past what primes will wait for. Underscoping leaves gaps that a C3PAO will challenge during pre-assessment, pushing the organization back into the same assessor queue. Recent CMMC FAQ revisions, including Revision 2.2, have focused heavily on correcting common scoping errors surfacing in live assessments.

Scope is architected, not described. That architectural work is what separates manufacturers who certify on schedule from those who keep slipping.

Where Does CUI Actually Live in a Manufacturing Environment?

The short answer: in many more places than engineering thinks. The long answer requires walking the plant.

Most defense manufacturing CUI falls under the Controlled Technical Information (CTI) category in the official CUI Registry. CTI includes drawings, three-dimensional CAD models, specifications, geometric dimensioning and tolerancing data, bills of materials, and manufacturing process documents. These are typically marked with DoD Distribution Statements B through F. For most tier-two and tier-three manufacturers, the highest-volume CUI exposure is customer-supplied technical data arriving from a prime contractor or original equipment manufacturer.

That data does not stay where engineering puts it. It follows the part.

The Shop Floor Itself

Assessors consistently cite shop floor CUI exposure as the single most common finding category in manufacturing assessments. The patterns repeat across facilities. Technical drawings display on CNC HMIs at the point of operation. Unencrypted tablets travel between inspection stations with first-article specifications loaded as PDFs. Printed specifications sit unsecured near machining centers. Job travelers ride with parts through the plant, quoting controlled dimensions in plain text. Setup books in machinist toolboxes hold copies of drawings. These are not exotic edge cases. They exist in nearly every defense manufacturing environment because they serve legitimate operational needs.

MES, ERP, and Quality Systems

The manufacturing execution system sits at Purdue Enterprise Reference Architecture Level 3 and routinely holds statistical process control data tied to specific controlled dimensions, first-article inspection records, and nonconformance documentation that references the original drawing. Enterprise resource planning platforms common in the defense supply chain, including Epicor, Plex, Infor, JobBOSS, IQMS, and E2, hold work orders, routing sheets, customer purchase orders, and scheduling records derived from the drawing package. Coordinate measuring machine programs and inspection plans derived from CTI carry the same sensitivity as the source drawing.

Controllers, Programs, and Removable Media

Engineering drawings get translated into G-code and programmable logic controller logic that can embed controlled dimensions, tolerances, and process parameters derived from CTI. USB drives used to move programs from engineering to the machine are ubiquitous in manufacturing and almost always in scope.

The Overlooked Digital Corners

Email archives between the company and the prime often contain the original RFQ attachments, and those attachments frequently include the full technical data package. OneDrive and Dropbox profile sync can silently replicate CUI from an endpoint to cloud services that lack FedRAMP authorization. Under DFARS 252.204-7012, cloud services handling CUI are required to meet FedRAMP Moderate baseline equivalency, which rules out most consumer-grade sync tools by default. Backup systems capture every CUI-bearing file on protected systems and become in-scope assets themselves. Managed service provider remote access tools that touch any CUI-handling endpoint pull the MSP into scope as a Security Protection Asset. The CEO's laptop, where the original RFQ attachment still lives months after award, belongs on the list as well.

Paper and Hybrid Workflows

The DoD clarified in CMMC FAQ Revision 2.2 that pure paper workflows do not by themselves trigger a CMMC assessment, but the moment paper CUI is scanned, photographed, emailed, uploaded, or printed from a system, that system enters scope. Hybrid paper-digital handling is the manufacturing norm, which means most paper CUI conversations eventually become digital CUI conversations.

When manufacturers map their CUI footprint for the first time, most discover it is three to five times larger than they assumed.

Legacy OT, IT Convergence, and the Specialized Assets Lever

The fear among manufacturers with older equipment is that a 2003-vintage programmable logic controller or an unpatchable supervisory control and data acquisition server automatically fails CMMC Level 2. That is not how the framework actually works.

Per 32 CFR 170.19(c)(1) Table 3, the CMMC Scoping Guide defines a category called Specialized Assets. It covers operational technology (PLCs, SCADA, HMIs, building management systems, physical access control panels), Internet of Things and Industrial Internet of Things devices, Government Furnished Equipment, Restricted Information Systems, and Test Equipment. The critical mechanics: Specialized Assets are part of the CMMC Assessment Scope, but they are not assessed against the full set of 110 NIST SP 800-171 controls. The organization must inventory them, document them in the System Security Plan (SSP), show them on the network diagram, and detail how they are managed under risk-based security policies. The assessor verifies the documentation and may perform a limited spot check if it is insufficient.

This is the legacy industrial control system lifeline. Older equipment that cannot support multifactor authentication, modern patching, or endpoint detection can coexist inside a compliant environment when properly categorized with specified compensating controls.

The trap is assuming the label alone is sufficient. Assessors require justification for Specialized Asset designation, not just the designation. If an unpatched PLC shares a VLAN with the CUI file server, the designation fails because the asset has unrestricted access paths to CUI.

The Purdue Enterprise Reference Architecture gives the organizing framework for this scope decision. Levels 0 through 3 cover the OT side (sensors and actuators, controllers, supervisory HMIs, MES and historians). Levels 4 and 5 cover IT (ERP, enterprise networks). A Level 3.5 Industrial Demilitarized Zone sits between them. For most manufacturers, the IDMZ is where the CMMC boundary should be drawn, with the OT side documented as Specialized Assets and the IT side treated as the CUI enclave.

Compensating controls that hold up in assessment include network segmentation with an IDMZ between IT and OT, identity-based microsegmentation overlays for environments where traditional VLAN segmentation cannot be fully retrofitted, data diodes for one-way telemetry flows out of OT, jump boxes with session recording for vendor remote access, and documented program transfer procedures that log and approve every file movement from engineering to the controller. Vendor remote access matters especially because Dragos reporting indicates that the majority of OT attacks, often around three-quarters of observed incidents, begin as IT breaches.

Practical CMMC Scoping Tactics That Actually Work

Four tactics do most of the work.

Start With Data Flow Mapping, Not the SSP

Most manufacturers write SSP narratives before mapping actual CUI flow. The result is documentation that drifts from reality the moment it is filed. The correct order is to map the flow first, classify assets against the five CMMC asset categories, and then write the SSP to match. Under NIST SP 800-171, organizations are explicitly required to identify where CUI is processed, stored, and transmitted. Data flow mapping is how that identification gets done with evidence behind it.

The workshop method that produces defensible results is a "book to bill" walkthrough, tracing one representative contract from arrival of the drawing package through production, shipment, and invoicing. Cross-functional participation is not optional. Engineering, quality, production scheduling, operations, business development or contracts, and at least one shop floor supervisor need to be in the room. Single-department mapping exercises commonly miss 40 to 60 percent of the actual CUI flows. The workshop should produce durable evidence artifacts, including annotated data flow diagrams, meeting notes, asset inventories, and categorization rationale, all of which can be reused during the C3PAO assessment to demonstrate how scope was derived.

Use the Enclave Strategy to Shrink Scope

An enclave is a logically or physically segmented environment where CUI is processed, stored, and transmitted, treated as a distinct CMMC Assessment Scope separate from the rest of the organization. The DoD explicitly recognizes this approach in the Program Rule. Published cost reductions versus enterprise-wide compliance range from 20 to 45 percent across documented case studies.

Architect the Right Kind of Enclave for a Real Plant

This is where marketed cloud enclaves often fail manufacturers. A pure cloud virtual desktop infrastructure enclave, the pattern sold to five-person engineering firms, does not survive contact with a real machine shop. Drawings have to reach CNC workstations at the point of operation. The architecture that works for manufacturers is hybrid:

• A cloud enclave, typically Microsoft GCC High or Azure Government, for email, document collaboration, contract management, and most knowledge-worker CUI handling. This layer inherits the bulk of the 110 controls through FedRAMP-authorized infrastructure.
• A hardened on-premise CUI segment for engineering workstations and the controlled-drawing path to the floor. This layer focuses on segmentation, access control, and physical security for the narrow path from engineering to production.
• An IDMZ separating the CUI environment from the OT network where PLCs, CNCs, and MES terminals operate as documented Specialized Assets.

Apply Scope-Limiting Levers That Hold Up Under Assessment

Several structural decisions consistently reduce scope without creating assessment risk:

• Separate commercial and DoD business units behind identity and network boundaries. If only certain programs handle CUI, other programs can stay out of scope entirely.
• Exclude departments that do not require CUI access, including most of finance, HR, sales, and marketing.
• Put operational technology on dedicated VLANs behind an IDMZ, with documented justification in the SSP.
• Use dedicated hardware for CUI handling, with no BYOD and no corporate Wi-Fi in scope for the CUI segment.
• Where possible, replace printed drawings on the floor with role-based access on viewer-only tablets.
• Establish removable media procedures with logging for the moments when physical transfer to a machine is unavoidable.

Why the SSP Has to Match What Is Actually Happening on the Floor

The SSP, network diagram, data flow diagram, and asset inventory are living documents, not filing cabinet artifacts. The 48 CFR final rule introduced a continuous compliance obligation and an annual affirmation requirement signed by a senior company official. Configuration Management is one of the 14 NIST 800-171 control families, with nine Level 2 practices dedicated specifically to tracking and approving change.

Manufacturing environments make this unusually difficult. New work cells come online. New CNCs get installed. ERP modules get added. Vendor technicians plug laptops into HMIs for diagnostics and leave behind connections no one documents. Contract machinists get onboarded for a rush job with access to the engineering share. Kaizen events reorganize physical layout every quarter. Each of these is a potential scope change, and most manufacturers have no process connecting operational changes to scope documentation.

The practical fix is a cadence paired with a trigger list. A quarterly scope review catches drift, and a defined trigger list forces immediate re-examination whenever any of the following occurs:

• A new contract involving CUI
• A new supplier receiving technical data
• A new hire with CUI access
• New hardware on the floor
• A new cloud service adopted anywhere in the organization
• A merger, acquisition, or significant reorganization

A lightweight change-impact workflow routes these events through a security review before they hit production.

The False Claims Act overlay elevates the stakes meaningfully. Annual affirmations now carry potential FCA liability. Submitting an affirmation against an SSP that no longer matches reality is not just an assessment risk. It becomes a legal risk the moment the senior official signs. Multiple leading defense-contractor law firms have published alerts on this point. The reframe that matters for executives: SSP maintenance is not a compliance chore, it is executive risk management that belongs on the general counsel's radar.

How Does CMMC Flow-Down Affect a Manufacturer's Scope?

A clean internal scope is not sufficient if CUI leaves the building through uncontrolled channels. Flow-down is driven by the data type shared, not by the prime's certification level. If a prime shares Federal Contract Information (FCI) with a subcontractor, that subcontractor needs Level 1. If a prime shares CUI, the subcontractor needs Level 2. The same logic applies when a manufacturer shares CUI with its own sub-tier suppliers.

Primes cannot see subcontractor SPRS certification status directly. They rely on supplier portals, the Cybersecurity Compliance and Risk Assessment questionnaire, and annual attestations to verify compliance. For a manufacturer sitting in the middle of the supply chain, this means the scoping exercise has to extend outward. A heat-treat vendor, a coating supplier, or a specialty machining house receiving the same drawing package is part of the scope conversation.

Practical implications: route supplier file sharing through secure portals rather than email, include CUI handling requirements in subcontract language, and maintain documented flow-down verification for every supplier that receives technical data. Flowing CUI to a sub-tier supplier carries an obligation to verify that supplier's ability to protect it, which means contract clauses, attestations, and documented verification records are part of your own scoping evidence, not just theirs. A manufacturer with a locked-down internal scope can still fail a prime contract review because of how it shares CUI with its own subs.

Frequently Asked Questions About CMMC Scoping in Manufacturing

What is Controlled Unclassified Information (CUI) in a manufacturing context?

In defense manufacturing, CUI most often takes the form of Controlled Technical Information (CTI): drawings, CAD models, specifications, GD&T data, BOMs, and manufacturing process documents supplied by a prime contractor or OEM, typically marked with DoD Distribution Statements B through F. Derived records, including work orders, routing sheets, and inspection plans that quote controlled dimensions, carry the same sensitivity in practice.

When does CMMC Level 2 certification become mandatory for manufacturers?

Phase 2 of the CMMC rollout begins November 10, 2026. On that date, third-party C3PAO Level 2 certification becomes a mandatory award condition for most new DoD contracts involving CUI. Full implementation across all applicable contracts is scheduled for November 10, 2028, but most manufacturers will face the requirement well before then as primes flow down requirements on new awards.

Do legacy PLCs and CNC machines automatically fail CMMC Level 2?

No. The CMMC Scoping Guide creates a Specialized Asset category for operational technology, IoT and IIoT, Government Furnished Equipment, Restricted Information Systems, and Test Equipment. These assets are in scope but are not assessed against the full 110 NIST SP 800-171 controls. They must be inventoried, documented in the SSP, shown on the network diagram, and managed under documented risk-based policies with appropriate compensating controls such as network segmentation.

Does encrypting CUI take a system out of CMMC scope?

No. Encryption reduces risk during transmission and at rest, but it does not remove a system from scope. If a system processes, stores, or transmits CUI, it is a CUI Asset regardless of whether the data is encrypted. Cloud services that handle CUI must meet FedRAMP Moderate baseline requirements per DFARS clause 252.204-7012.

How much does CMMC Level 2 certification cost for a small manufacturer?

Costs vary widely by size, existing security maturity, and scope architecture. Published benchmarks for small and mid-sized manufacturers commonly fall between $75,000 and $150,000 for total first-year investment, with properly scoped enclave approaches coming in 20 to 45 percent below enterprise-wide approaches for comparable organizations. C3PAO assessment fees alone range from approximately $15,000 for a tightly scoped enclave to more than $100,000 for a sprawling full-organization boundary.

What is the difference between overscoping and underscoping?

Overscoping includes systems and users that do not need to be in the CMMC boundary, which inflates the cost of implementation, lengthens the assessment timeline, and commits the organization to controls on systems that never required them. Underscoping omits systems that actually handle CUI, which assessors will challenge during pre-assessment and force the organization to expand scope on the spot, often delaying certification by months. Both failure modes cost more than right-sized scope architected from the start.

What is a CUI enclave and why does it matter?

A CUI enclave is a logically or physically segmented environment where CUI is processed, stored, and transmitted, treated as a distinct CMMC Assessment Scope separate from the rest of the organization. The enclave approach is explicitly recognized in CMMC guidance and is the most effective lever for reducing assessment scope, assessment cost, and ongoing compliance burden without sacrificing security posture. For manufacturers, a hybrid enclave combining cloud collaboration (GCC High or Azure Government) with a hardened on-premise CUI segment typically fits the physical realities of a shop floor better than a pure cloud VDI approach.

The Bottom Line: Walk the Plant Before an Assessor Does

The manufacturers who will certify cleanly in the twelve to eighteen months leading up to Phase 2 are the ones catching the tablet, the print queue, the scheduler's inbox, and the USB drive before a C3PAO does. The work is not a compliance audit. It is a plant walkthrough with a different set of questions.

A Practical Starting Checklist

1. Map every CUI entry point, including prime portals, email, physical mail, removable media, and vendor handoffs.
2. Trace one representative contract from book to bill. Walk it physically. Note every system and location the drawing touches.
3. Inventory every device and location where controlled technical data appears, including tablets, HMIs, printers, toolboxes, and vehicles.
4. Categorize against the five asset types (CUI, Security Protection Asset, Contractor Risk Managed Asset, Specialized, Out of Scope) before writing a line of SSP narrative.
5. Test the boundary. If an assessor walked the floor tomorrow, what would they see that leadership did not?

Why Getting Scope Right Now Is a Competitive Decision

Three realities drive the timing. Phase 2 certification becomes mandatory November 10, 2026. C3PAO capacity is already constrained, with reported backlogs of six to twelve months. Primes are actively filtering their supply chains right now, not waiting for the deadline.

Manufacturers who architect scope correctly in the next year gain structural advantage: earlier certification, faster prime qualification, and stronger position in contract negotiations. Those who do not will be waiting in the assessor queue while their certified competitors take their work. Scope is not a paperwork exercise. It is the decision that determines whether certification is achievable on the timeline the market is already enforcing.

---

About the Author

Navneet Lounsberry brings over two decades of enterprise sales and business development experience across IBM, SAP, Manhattan Associates, UKG, and Idenhaus Consulting, where her work spanned identity and access management and cybersecurity compliance, including CMMC. A Georgia Tech graduate, she writes about how enterprise buyers in regulated industries actually evaluate, procure, and operate compliance programs.

Copyright © 2026, Full Throttle Media, Inc. FTM #fullthrottlemedia #inthespread #sethhorne