Access Control for OT and IIoT in Machine Shops: CMMC Without Breaking Production

Executive summary

Access control in a machine shop is not just a password policy.

It is who can open the drawing, who can change the CNC program, who can remote into the machine network, who can plug in a laptop, who can approve vendor access, who can move files between engineering and the floor, and who still has access after they leave.

That gets messy fast.

Most small manufacturers were not built like a software company. They have old controllers, vendor-managed machines, shared shop-floor terminals, CAD/CAM workflows, ERP data, customer portals, network drops that predate the current IT provider, and now IIoT sensors or gateways promising visibility into production.

Then CMMC shows up and everyone asks the wrong first question:

"Do we have to put all of this in scope?"

The better first question is:

"What information and access paths could put contract data, production, or the business at risk?"

NIST SP 800-82 Rev. 3 is useful here because it treats operational technology as its own environment, not just normal IT with different labels. CMMC and NIST SP 800-171 matter because defense contractors still need to protect Federal Contract Information and Controlled Unclassified Information. The trick is tying those two worlds together without pretending a CNC controller, an engineer's laptop, and a cloud email account should all be handled the same way.

The goal is not enterprise theater.

The goal is controlled access, truthful scope, usable documentation, and practical safeguards that a small plant can actually operate.

What OT and IIoT mean here

OT is operational technology. In a manufacturing plant, that usually means the systems that run, monitor, support, or interact with production equipment.

Think CNC controllers, PLCs, HMIs, robotics, machine monitoring systems, test equipment, gauges, production workstations, DNC systems, and the network equipment that lets those things communicate.

IIoT is industrial internet of things. In plain language, it is the sensor, gateway, device, or service layer added to collect production data, monitor equipment, support maintenance, or push machine information into dashboards and cloud platforms.

The reason the distinction matters is simple: OT and IIoT often sit close to production, but they may also create paths into business systems, customer data, engineering files, remote support tools, or cloud services.

That is why access control cannot stop at "who has a Windows login?"

The manufacturing access problem is different

In an office environment, access control usually starts with users, accounts, MFA, groups, devices, and applications.

In a manufacturing environment, that is only part of the story.

A plant may also need to account for:

• CNC controllers and machine tools.
• PLCs, HMIs, robots, gauges, and inspection systems.
• DNC or drip-feed systems moving programs to machines.
• Engineering workstations with CAD/CAM software.
• Shared shop-floor computers or terminals.
• ERP, MES, QMS, scheduling, and maintenance systems.
• Customer portals used to receive drawings, specifications, or purchase orders.
• IIoT gateways, sensors, and cloud dashboards.
• Remote access tools used by vendors, machine builders, MSPs, or integrators.
• USB drives, local folders, network shares, and old habits that nobody wrote down.

Some of those assets may touch CUI directly. Some may only affect production. Some may create a path into systems that hold CUI. Some may be business-important but outside the CMMC assessment boundary.

That distinction matters.

If everything becomes "CMMC scope," the project becomes unaffordable and confusing. If everything on the floor is treated as "not IT," the business usually leaves giant access paths unmanaged.

Neither extreme is good consulting.

CMMC does not automatically make every machine a compliance asset

This is where a lot of manufacturers need nuance.

CMMC is about protecting FCI and CUI in defense contractor environments. NIST SP 800-171 focuses on protecting the confidentiality of CUI in nonfederal systems. OT security also cares about safety, reliability, uptime, process integrity, and physical consequences.

Those overlap, but they are not identical.

A lathe that never stores CUI, never receives CUI-derived programs, and cannot reach the CUI environment may not belong in the same bucket as the engineering workstation that downloads drawings from a defense customer portal.

A shop-floor computer used to pull controlled drawings from a shared drive is a different story.

An IIoT gateway that bridges the machine network into a cloud platform is also a different story, especially if the gateway has credentials, remote access, or visibility into systems that support the CUI environment.

The CMMC scoping guidance is helpful because it recognizes asset categories beyond a simple "in or out." It talks about CUI assets, security protection assets, contractor risk managed assets, and specialized assets. OT, IoT, IIoT, test equipment, and restricted information systems may need special treatment instead of a lazy answer.

Plain English:

• If it stores, processes, or transmits CUI, slow down and treat it seriously.
• If it protects the CUI environment, it may matter even if it does not hold CUI.
• If it connects to systems that hold CUI, the access path matters.
• If it is specialized OT or IIoT, document how it is handled instead of pretending normal endpoint controls always fit.
• If it is truly outside the data flow and cannot affect the protected environment, do not drag it into scope just to look thorough.

The business needs a truthful boundary. Not the smallest boundary someone can argue for. Not the biggest boundary a consultant can bill against. The truthful one.

Start with paths, not products

Most plants should not start this problem by buying a tool.

Start by drawing the paths.

You do not need a perfect Visio diagram. A whiteboard, spreadsheet, or simple network sketch is enough for the first pass.

Map these paths:

• How customer files, drawings, specifications, and purchase orders arrive.
• Where engineering stores and edits those files.
• How programs, work instructions, and quality records move to the floor.
• Which shop-floor systems can reach office systems.
• Which users can access engineering, production, and administrative systems.
• Which vendors can remote in, how they authenticate, and who approves it.
• Which IIoT devices send data out to cloud services.
• Which backups, logs, and support tools can reach the environment.

This is not glamorous. It is also where the money gets saved.

If you understand the paths, you can make targeted changes. If you do not understand the paths, every recommendation turns into "buy a platform" or "segment everything" without knowing what that actually means for production.

A realistic example

Imagine a defense customer sends a controlled drawing through a portal.

Engineering downloads it, stores it in a restricted project folder, uses CAD/CAM software to create a program, sends that program to a DNC system, and then the shop-floor operator loads it at the machine.

On paper, that might look like one drawing and one machine.

In access-control reality, it may involve:

• The customer portal account.
• Email or notification access.
• The engineering workstation.
• The file share or cloud storage location.
• CAD/CAM software and local working folders.
• The DNC system.
• The shop-floor terminal.
• The operator account or shared machine login.
• Backups.
• Vendor or MSP access to any of those systems.

That is why CMMC scope cannot be guessed from the machine list alone.

You have to follow the work.

The access-control model that works on a shop floor

A manufacturer should think about access control in layers.

Not because frameworks like layers. Because one control will not survive this environment by itself.

Human access

This is the normal identity problem.

Who has accounts? What groups are they in? Which accounts are shared? Which accounts are privileged? Does MFA protect email, VPN, remote access, cloud storage, and admin portals? Are terminated users removed quickly? Are vendors and contractors separated from employees?

In many SMBs, this alone finds obvious problems.

A former programmer still has VPN access. A shared engineering account can open every customer folder. The MSP has a single shared admin account. The shop-floor computer is always signed in as a user with too much access. A vendor remote tool was installed for one support call and never removed.

That is access control work. It is not fancy. It is real.

System access

This is what systems can talk to other systems.

A plant can have good user accounts and still have a flat network where every office laptop can reach every shop-floor device. That is not good enough, especially when unsupported or fragile equipment lives on that same network.

The affordable starting point is usually basic segmentation:

• Separate office, server, guest, and production networks.
• Limit traffic between those networks to known business needs.
• Put vendor remote access behind an approval process instead of leaving direct access open.
• Use a jump host or controlled remote access point for administrative work.
• Block direct inbound internet access to OT and IIoT devices.
• Document the few flows that are allowed.

This does not require a Fortune 500 budget. Many plants already own enough firewall and switching capability to start. The hard part is deciding what should be allowed.

One practical rule helps: default-deny between office and production networks, then allow the few documented flows the business actually needs.

That might be engineering to DNC. It might be backups from a server to a production workstation. It might be a jump host to a specific support subnet. It should not be "everything can talk to everything because that is how it has always worked."

Data access

This is the file and information problem.

A machine may not "hold CUI" in the way a file server does, but the workflow around it might.

If controlled drawings are downloaded from a customer portal, saved to a shared engineering folder, converted into CAM output, moved to a DNC system, and then accessed from the floor, the access-control discussion has to follow that path.

The question is not only "Where is the drawing?"

It is:

• Who can open it?
• Who can copy it?
• Who can move it to the floor?
• Who can modify the program?
• Who can send it to a supplier?
• Where does it get backed up?
• What gets left behind on local machines?

That is where policy, permissions, folder structure, and training actually matter.

Physical access

OT access is often physical.

A person standing at a machine, panel, workstation, or network cabinet may be able to do things that no cloud access policy can prevent. That does not mean every plant needs airport security. It means physical access needs to be part of the story.

Practical controls might include locked network cabinets, badge or key control, visitor escort rules, controlled USB use, screen lock expectations, camera coverage in sensitive areas, and a simple process for who can connect laptops to production equipment.

If a control only exists in Microsoft 365 but the real change happens through a USB stick at a machine, the control story is incomplete.

Vendor and delegated access

This is the one that hurts manufacturers the most.

Vendors are necessary. Machine builders, integrators, ERP consultants, MSPs, and support providers keep the place running.

But vendor access cannot be magic.

A good vendor access process answers:

• Who is allowed to request access?
• Who approves it?
• Is access always on, or time-limited?
• Is MFA required?
• Is the account named to a person or shared by a vendor team?
• What can the vendor reach after connecting?
• Are sessions logged?
• How is access removed after the work is done?

You do not need to buy an expensive privileged access platform on day one. You do need to stop treating vendor remote access like a side door nobody owns.

IIoT deserves special skepticism

IIoT can be useful.

Machine monitoring, predictive maintenance, utilization dashboards, energy monitoring, environmental telemetry, and quality signals can all help the business.

The risk is that IIoT is often sold as "just a sensor" when it is really a new computer, a new network bridge, a new cloud relationship, and a new remote support path.

Before putting an IIoT device in a plant, ask:

• What network does it connect to?
• Does it need inbound access, or can it send outbound only?
• What cloud service receives the data?
• What credentials are stored on the device?
• Can the vendor remotely manage it?
• Can it see machine data, production data, customer identifiers, part numbers, drawings, or process parameters?
• Is firmware update and vulnerability handling documented?
• What happens if the vendor account is compromised?
• How do we remove it cleanly if the contract ends?

The answer is not "never use IIoT."

The answer is "do not let a visibility project become an unmanaged access path."

For CMMC purposes, the question is whether the IIoT device touches CUI, supports or protects the CUI environment, or creates a path into systems that matter. For business risk, the question is also whether it can disrupt production or expose sensitive operational information.

Both questions matter.

A useful middle position is to pilot IIoT in a contained lane: outbound-only communication where possible, no shared credentials, no unmanaged bridge into the office network, documented vendor access, and a clear answer on whether the data being collected has contract, customer, or CUI sensitivity.

Technologies that can help, in the right order

There are useful technologies here. They just need to be sequenced.

Low-cost foundation

This is where most SMBs should start:

• Asset inventory for production systems, engineering workstations, remote access tools, and IIoT devices.
• Named user accounts instead of shared accounts where practical.
• MFA for email, VPN, remote access, cloud systems, and admin portals.
• Password manager for privileged, vendor, and break-glass credentials.
• Basic network segmentation using existing firewall and managed switch capabilities.
• Documented vendor access approvals.
• Access review for employees, vendors, MSPs, and former users.
• Backups of critical configurations, programs, and documentation.
• A simple network diagram and data-flow summary.

None of that is exotic.

It is also where many plants get the highest return.

Middle layer

Once the foundation is moving, consider:

• A dedicated jump host for administrative access into production networks.
• VPN or zero trust remote access with MFA and narrower reach.
• Central logging for firewall, VPN, identity, endpoint, and key server events.
• Endpoint protection on supported Windows shop-floor and engineering systems.
• Application control for systems where software should rarely change.
• Separate admin accounts for privileged work.
• More formal change control for firewall rules, vendor access, and production-system changes.

This is usually where the program starts feeling real.

It also creates evidence for CMMC-related practices without pretending every old controller can run a modern security agent.

Mature or higher-risk layer

Some environments need more:

• Passive OT asset discovery or network monitoring.
• Session recording for vendor or privileged remote access.
• Privileged access management.
• Network access control.
• Dedicated OT firewall zones or industrial DMZ patterns.
• Security monitoring that understands OT protocols.
• Formal tabletop exercises for production-impacting incidents.

These can be worthwhile. They can also become expensive shelfware if the plant has not solved the basics.

Buy maturity in the right order.

What not to do

A few mistakes are common enough to call out.

Do not put endpoint agents on fragile OT assets without testing. Some systems cannot tolerate normal IT tooling. NIST SP 800-82 spends a lot of time on OT constraints for a reason. Availability and process impact matter.

Do not scan production networks aggressively because a checklist says "vulnerability management." Active scanning can be fine in some places and risky in others. Use maintenance windows, vendor guidance, passive methods, test segments, and change control where needed.

Do not leave vendor access permanently open because support is inconvenient. Convenience is not a control strategy.

Do not assume the MSP understands the plant. Many MSPs are good at office IT and weak around OT boundaries. That does not make them bad. It means someone needs to define the model.

Do not drag every machine into the CMMC boundary to look conservative. Over-scoping can make compliance harder without improving security.

Do not exclude shop-floor paths just because the asset is old or weird. If the asset touches CUI or provides a path into the CUI environment, it needs to be understood.

Do not buy an OT security platform before knowing who will operate it. Alerts without ownership are just noise with a nice dashboard.

The pattern is simple: do not force normal IT controls blindly onto OT, and do not use OT constraints as an excuse to do nothing.

How this ties back to CMMC

CMMC will not ask a small manufacturer to become a giant enterprise overnight.

It will ask the business to protect FCI and CUI according to the applicable level and assessment path. For Level 2, that brings the NIST SP 800-171 requirement set into the conversation.

NIST SP 800-82 is the better source for understanding OT security constraints. NIST SP 800-171 is the CUI protection baseline that drives the Level 2 CMMC conversation. The DoD CMMC resources explain how the program scopes and assesses that work. CISA's Cross-Sector Cybersecurity Performance Goals and the NIST Cybersecurity Framework can help with broader prioritization, but they do not replace the CMMC-specific requirements when a contract puts CMMC in play.

That source stack matters because it keeps the advice grounded.

Use OT guidance to avoid breaking production. Use CMMC and 800-171 guidance to protect CUI. Use risk frameworks to prioritize the work like a business.

Access control touches a lot of that work.

It supports:

• Limiting system access to authorized users and processes.
• Managing privileged access.
• Controlling remote access.
• Separating duties where practical.
• Protecting wireless, external, and mobile access paths.
• Identifying and authenticating users and devices.
• Auditing access-related events.
• Controlling configuration changes.
• Defining system boundaries in the SSP.

But CMMC also needs evidence.

For OT and IIoT access control, useful evidence might include:

• Network diagrams showing office, engineering, server, production, guest, and vendor access zones.
• Data-flow notes showing where FCI and CUI enter, move, and leave.
• Asset inventory with OT, IIoT, engineering, and support systems identified.
• Access review records for users, vendors, MSPs, and privileged accounts.
• Firewall or VPN rules tied to business needs.
• Vendor access approvals and session records.
• MFA configuration screenshots for remote access and identity systems.
• Policies for remote access, removable media, account management, and change control.
• Exception records for specialized assets that cannot support normal controls.
• Backup and recovery records for critical programs, configurations, and systems.

That evidence does not need to be theatrical. It needs to be organized and true.

If your SSP says the production network is segmented, show the diagram and firewall rules. If vendor access is time-limited, show the process. If a specialized asset cannot support a normal control, explain the compensating approach and who accepted the risk.

This is where small manufacturers can compete with bigger companies: be clearer, more disciplined, and less fake.

A practical 90-day path for an SMB

If you are starting from a flat network and a pile of tribal knowledge, do not try to fix everything in one heroic project.

Use a sequence.

First 30 days: find the truth

Build the map.

• List the machines, controllers, engineering workstations, shop-floor computers, IIoT devices, servers, cloud systems, and remote access tools.
• Identify where FCI and CUI may enter, live, or move.
• Identify who has access today, including vendors and MSPs.
• Document the current network layout.
• Find obvious shared accounts, stale accounts, and always-on vendor paths.
• Separate production uptime risks from CMMC/CUI risks.

The deliverable is not a perfect program. It is a truthful starting point.

Days 31 to 60: close obvious access gaps

Fix the cheap, high-value problems.

• Remove former users and stale vendor accounts.
• Require MFA on remote access and cloud identity systems.
• Replace shared privileged access with named accounts where practical.
• Create a vendor access approval process.
• Start segmenting the production network from office and guest networks.
• Lock down direct internet exposure.
• Put privileged and break-glass credentials in a password manager.
• Decide where controlled drawings and programs are allowed to live.

This is where the plant starts feeling less ad hoc.

Days 61 to 90: make it sustainable

Turn the fixes into an operating rhythm.

• Schedule quarterly access reviews.
• Add OT and IIoT assets to the asset inventory.
• Document approved data flows and remote access paths.
• Add evidence locations to the SSP or evidence tracker.
• Review backups for machine programs, key configurations, and business systems.
• Identify specialized-asset exceptions and compensating practices.
• Brief leadership in plain English on what changed, what remains, and what decisions require budget.

By the end of 90 days, the company should know its access story much better.

Not perfect. Better.

Better is valuable when it is real.

The budget conversation

Small manufacturers do not have unlimited money for cybersecurity.

That is not a character flaw. It is reality.

The right budget conversation is not "What is the best possible architecture?"

The right question is:

"What reduces the most access risk while keeping production moving and supporting our contract obligations?"

In many environments, the first dollars are better spent on scoping, segmentation, identity cleanup, vendor access control, and documentation than on a specialized monitoring platform.

A reasonable first budget might include:

• A few hours of network discovery and diagramming.
• Firewall or switch configuration cleanup.
• MFA and identity hardening.
• Password manager seats for admins and key users.
• Time from the MSP or integrator to clean up remote access.
• Documentation work for the SSP, access control policy, vendor access procedure, and evidence tracker.
• Backup verification for programs and configurations that would hurt production if lost.

But if it gives leadership a clear scope, cuts off stale access, reduces vendor exposure, creates an OT boundary, and produces evidence for CMMC, it is better than buying something impressive that nobody operates.

The consulting answer should be boring enough to work

Good advice for OT and IIoT access control should not sound like a threat briefing or a vendor pitch.

It should sound like this:

• Here is what information matters.
• Here is where it moves.
• Here is who can reach it.
• Here is where the shop floor creates special constraints.
• Here is what we can fix cheaply.
• Here is what needs budget.
• Here is what belongs in the SSP.
• Here is what evidence would support the claim.
• Here is what we should not touch during production without a plan.

That is the work.

It is not glamorous. It is also the difference between a security program and a pile of tools.

Final thought

Access control in a manufacturing plant is where cybersecurity becomes real.

It runs into old machines, production pressure, vendor habits, customer data, engineering workflows, budget limits, and CMMC language that was not written for the way many shops actually operate.

That does not make the work impossible.

It means the work has to be honest.

Do not start by asking whether every asset is in scope. Start by understanding what the asset can access, what data moves through it, what business process depends on it, and what would happen if that access were abused.

Then build controls in layers.

Named users where possible. MFA where it matters. Segmentation before panic. Vendor access with ownership. IIoT with skepticism. Documentation that matches reality. Evidence that can be found when someone asks.

That is the path that lets a small manufacturer improve security, support CMMC readiness, and avoid breaking production in the process.

If you want help mapping OT and IIoT access paths, defining a truthful CMMC scope, or turning the mess into a practical roadmap, book a consultation with Trawvid Sec. Bring the network sketch, the customer requirement, the vendor access problem, or the one machine nobody wants to talk about. That is usually where the useful conversation starts.