A 90-Day OT and IIoT Security Roadmap for Small Manufacturers

Executive summary

A small manufacturer does not need a giant cybersecurity transformation project to start reducing OT and IIoT risk.

It needs a sequence.

The first 90 days should not be used to buy every tool, rewrite every policy, or pretend the plant can become a clean enterprise network overnight. The first 90 days should be used to find the truth, close the obvious access gaps, and leave the business with an operating rhythm it can keep using.

That means a real inventory. A rough but useful network map. A short list of vendor and remote access paths. A clean view of where Federal Contract Information (FCI), Controlled Unclassified Information (CUI), engineering data, machine programs, quality records, and production data may move. A handful of high-value fixes. Evidence that the work happened.

NIST SP 800-82 Rev. 3 is clear that operational technology has safety, reliability, and performance constraints that normal IT guidance can miss. NIST SP 800-171 matters when CUI is involved. The Department's CMMC resources matter when defense contract requirements apply. NIST CSF 2.0 is useful because it pushes the business to understand current state, target state, governance, protection, detection, response, and recovery as one risk-management conversation.

The point of a 90-day roadmap is not to declare victory.

The point is to stop guessing.

If you need the access-control foundation first, start with Access Control for OT and IIoT in Machine Shops. This post focuses on the first 90 days of practical work.

Who this roadmap is for

This is for small manufacturers, machine shops, industrial suppliers, and DoD-adjacent businesses that have some mix of:

• CNC machines, PLCs, HMIs, robotics, gauges, test equipment, or shop-floor workstations.
• IIoT sensors, gateways, dashboards, cloud monitoring, or vendor-managed machine visibility.
• Engineering workstations, CAD/CAM workflows, DNC systems, ERP, MES, QMS, or maintenance platforms.
• Remote access from MSPs, integrators, OEMs, machine builders, or software vendors.
• Customer portals, drawings, specifications, quality records, purchase orders, or controlled technical information.
• CMMC, DFARS, NIST SP 800-171, supplier questionnaire, insurance, or customer pressure.

The roadmap also assumes a normal SMB constraint: the business has limited time, limited budget, and production cannot stop just because security work sounds important.

That constraint is not an excuse to do nothing. It is the reason the work needs to be sequenced.

A right-sized plan should reduce risk without breaking production. It should also avoid the opposite failure: treating every old machine, shared terminal, vendor habit, and unmanaged gateway as "too operational" to question.

What success looks like after 90 days

The goal is not perfection.

By day 90, the company should be able to answer these questions without relying on tribal memory:

• What OT and IIoT assets are in the environment?
• Which systems support production, engineering, quality, maintenance, and administration?
• Where do FCI, CUI, controlled drawings, machine programs, and sensitive operational data enter, live, move, and leave?
• Who can remotely access the environment?
• Which vendor paths are always on?
• Which accounts are shared, stale, privileged, or poorly protected?
• Which network paths are allowed between office, engineering, server, production, guest, and vendor-access zones?
• Which assets cannot support normal endpoint, patching, or identity controls?
• Which controls are implemented, which are planned, and which require leadership decisions?
• Where is the evidence?

This is why the first 90 days should produce artifacts, not just activity.

Useful artifacts include an asset inventory, a network sketch, a data-flow map, a vendor access register, an access cleanup record, a prioritized risk register, a basic evidence tracker, a backup and restore note, and a short remediation roadmap for the next quarter.

Those artifacts are useful even if the business is not ready for a formal assessment. They make the environment legible.

Days 1 to 30: find the truth

The first month is discovery with enough cleanup to remove obvious risk.

Do not start with a full tool rollout. Start with the map.

Build the asset inventory

Create a single list of the assets that matter to production, engineering, quality, maintenance, remote support, and business operations.

Include:

• Machine controllers, PLCs, HMIs, robotics, gauges, inspection systems, and shop-floor terminals.
• Engineering workstations, CAD/CAM systems, DNC systems, and file transfer tools.
• Servers, network shares, cloud storage, ERP, MES, QMS, maintenance systems, and customer portals.
• IIoT sensors, gateways, vendor appliances, cloud dashboards, and monitoring tools.
• Firewalls, switches, wireless networks, VPNs, remote access tools, jump boxes, and MSP management agents.
• Backup systems, logging systems, endpoint tools, password managers, and identity systems.

For each item, capture the owner, location, business function, vendor, operating system or firmware if known, support status if known, network location, remote access method, and whether the asset may process, store, transmit, or protect FCI or CUI.

Keep the first version practical. A spreadsheet is fine. The evidence is the inventory itself, plus the date and the people who helped validate it.

Follow the data and access paths

A machine list is not enough.

Follow the work.

Map how customer files arrive. Map where drawings are stored. Map how programs are created and moved to the floor. Map where quality records and inspection results are stored. Map who can approve changes, who can remote in, who can move files, and who can administer the systems.

This matters for CMMC because NIST SP 800-171 focuses on components that process, store, or transmit CUI, or that protect those components. It matters for production risk because a system can be outside the CUI path and still be operationally critical.

The practical output is a simple data-flow and access-flow note:

• Customer portal to engineering.
• Engineering to file storage.
• File storage to CAD/CAM.
• CAD/CAM to DNC or shop-floor terminal.
• Shop-floor system to machine.
• Vendor or MSP remote access into the environment.
• IIoT data outbound to cloud services.
• Backups and logs for the systems above.

The goal is not a perfect drawing. The goal is a truthful one.

Identify the obvious access problems

In the first 30 days, look for the issues that create the most risk for the least mystery:

• Former employee accounts that still work.
• Shared privileged accounts.
• Vendor accounts that are always enabled.
• Remote access without MFA.
• Direct inbound internet exposure to OT or IIoT devices.
• Shop-floor terminals with broad file access.
• Engineering accounts that can reach everything.
• MSP or vendor tools that nobody internally owns.
• Local admin passwords reused across systems.
• Customer files stored in unmanaged personal locations.

Do not spend the whole first month debating the perfect architecture. Remove or disable access that clearly should not exist. Record what changed.

The evidence is simple: access review notes, account disablement records, MFA screenshots where appropriate, vendor access decisions, and a dated risk list.

Days 31 to 60: close the high-value gaps

The second month is where the business starts changing the environment.

The work should still be controlled. OT systems can be fragile. NIST SP 800-82 warns that normal IT changes can have production, reliability, or safety consequences. That is especially true for patching, scanning, endpoint tooling, and network changes.

The answer is not paralysis. The answer is change discipline.

Put remote access under ownership

Vendor and MSP access is usually the highest-return fix.

Create a vendor access register. For each vendor, record the business owner, system accessed, access method, MFA status, approval process, normal hours, emergency process, logging available, and how access is removed when work is done.

Then make a small set of decisions:

• No vendor remote access without a named internal owner.
• No standing access unless the business can justify it.
• MFA for remote access wherever the platform supports it.
• Named accounts where practical.
• A documented approval path for support sessions.
• A record of emergency exceptions and who approved them.

A small manufacturer may not need a full privileged access management platform on day 45. It does need to stop treating remote access as a side door nobody owns.

Start basic segmentation

Segmentation does not have to mean a full industrial redesign in month two.

Start with the boundaries that matter:

• Office network.
• Engineering systems.
• Servers and storage.
• Production or machine network.
• Guest wireless.
• Vendor remote access.
• IIoT gateways and cloud-connected devices.

The first practical rule is simple: reduce unnecessary traffic between zones.

If office laptops do not need to talk directly to machine controllers, block that path. If engineering needs to send programs to a DNC system, document that path and allow only what is needed. If an IIoT gateway only needs outbound communication to a cloud service, do not let it become an unmanaged bridge into the office network.

This is where many shops can improve with existing firewall and switch capability. The hard part is not always technology. The hard part is deciding what the business actually needs.

The evidence is a network diagram, firewall or switch change records, and a short allowed-flow list.

Treat patching like production maintenance

Patch management in OT is not "patch everything immediately" and it is not "never patch anything."

NIST SP 800-40 frames patching as preventive maintenance. NIST SP 800-82 adds the OT caveat: patches may need offline testing, vendor coordination, regression testing, planned outages, and compensating controls when patching is delayed.

For days 31 to 60, build the process:

• Identify supported Windows shop-floor systems, engineering systems, servers, and remote access components.
• Identify unsupported or fragile systems that need compensating controls.
• Subscribe to vendor security notifications for key OT, IIoT, firewall, remote access, and engineering tools.
• Define where active scanning is allowed, where passive discovery is safer, and where vendor guidance is required.
• Schedule patch windows for supported systems.
• Record exceptions and compensating controls.

The useful evidence is a patch decision log. It should say what was patched, what was deferred, why it was deferred, who accepted the decision, and what control reduces exposure in the meantime.

Decide where controlled information is allowed to live

If the business handles FCI or CUI, the roadmap has to address information location.

Controlled drawings, specifications, programs, and quality records should not drift across personal email, unmanaged USB drives, old local folders, shared shop-floor accounts, and vendor portals without ownership.

Pick the approved locations. Limit access. Document the path from customer portal to engineering to production. Decide whether shop-floor systems need access to controlled files or whether a safer transfer path can be used.

This is where the roadmap connects directly to the truthful CMMC boundary. If the file path is vague, the CMMC scope will be vague. If the scope is vague, the SSP and evidence story will be weak.

Days 61 to 90: make it sustainable

The third month is where the business turns cleanup into a program.

This is not paperwork for its own sake. It is the operating rhythm that keeps the environment from sliding back.

Create the evidence tracker

Build a basic evidence tracker tied to the systems and risks discovered in the first two months.

Include:

• Asset inventory location.
• Network diagram location.
• Data-flow and access-flow notes.
• Vendor access register.
• Access review records.
• MFA and remote access configuration evidence.
• Backup and restore notes.
• Patch and exception decision log.
• Incident contact sheet.
• Policy or procedure locations.
• SSP sections that need updates if CMMC applies.

If CMMC applies, connect this tracker to the applicable NIST SP 800-171 or CMMC evidence approach. If CMMC does not apply, the tracker still has value because it shows what the business can prove about its environment.

Evidence should not be scattered across email threads and memory.

Build the incident and recovery path

A 90-day OT and IIoT roadmap should include incident readiness.

The first version can be short:

• Who can make a production-impacting decision?
• Who can disable vendor access?
• Who can contact the MSP, insurer, legal counsel, prime contractor, customer, or machine vendor if needed?
• Which systems must be restored first?
• Where are machine programs, configurations, firewall backups, server backups, and cloud backups stored?
• Has anyone tested a restore?
• What logs are available for remote access, identity, firewall, endpoint, and key servers?

NIST SP 800-61 Rev. 3 ties incident response into broader cybersecurity risk management. For a small plant, the practical version is a dated contact sheet, a restore note, and a decision tree for production-impacting events.

Do not wait for a ransomware event or vendor compromise to decide who has authority to shut off access.

Update the SSP or security plan

If the business has a System Security Plan, update it with what was learned.

If the business does not have an SSP because CMMC does not apply, write a short security plan anyway. It can be simpler, but it should still explain the environment, owners, access paths, key controls, known gaps, and next decisions.

For CMMC pressure, this is where the 90-day roadmap should feed the broader CMMC readiness plan. Do not let the roadmap live in a separate spreadsheet while the SSP tells a different story.

The SSP or security plan should answer:

• What is in scope?
• What is out of scope?
• Which assets are specialized or operationally constrained?
• Which external service providers affect the environment?
• Which controls are implemented?
• Which gaps remain?
• Which risks require leadership acceptance or funding?

The plan does not need to sound impressive. It needs to match reality.

What not to do in the first 90 days

A bad roadmap can create as much risk as no roadmap.

Do not aggressively scan production networks without understanding the environment, maintenance windows, and vendor constraints.

Do not install normal endpoint tooling on fragile OT assets without testing.

Do not let an IIoT project create a new bridge between production and cloud systems without reviewing data flows, credentials, remote support, and removal procedures.

Do not over-scope every machine into the CMMC boundary because nobody wants to make distinctions.

Do not under-scope shop-floor paths because the equipment is old or inconvenient.

Do not buy an OT monitoring platform before deciding who will respond to alerts.

Do not claim segmentation because there is a diagram. Prove it with rules, routes, and observed paths.

Do not confuse a POA&M with progress. A gap with no owner, date, decision, or evidence expectation is not a plan.

The common pattern is overreaction on paper and underreaction in operations. Avoid both.

The leadership briefing at day 90

The most valuable day-90 deliverable is a plain-language leadership briefing.

It should fit in a few pages:

• What we found.
• What we fixed.
• What still worries us.
• What CMMC, CUI, insurance, customer, or production risks are tied to those findings.
• What decisions require budget.
• What decisions require ownership.
• What evidence exists.
• What the next 90 days should address.

This is where the roadmap becomes useful to the business.

Leadership does not need every firewall rule. Leadership does need to know whether the plant still has always-on vendor access, unsupported systems without compensating controls, uncontrolled CUI paths, missing backups, unmanaged IIoT gateways, or an SSP that does not match reality.

The next phase should be driven by that briefing, not by whatever product demo happens to land in the inbox.

The practical next step

The first 90 days should make the plant easier to explain, safer to operate, and more credible under customer or CMMC pressure.

Start with truth. Find the assets, paths, accounts, vendors, and data. Close the obvious access gaps. Segment the paths that should not be open. Treat patching and scanning like production work, not generic IT work. Put evidence where it can be found. Brief leadership in normal language.

That is not a complete security program.

It is the start of one.

Trawvid Sec helps small manufacturers and regulated businesses turn messy OT, IIoT, CMMC, and access-control questions into practical security program work. If you need help mapping the environment, defining a truthful scope, or turning the first 90 days into a plan the business can actually operate, start with CMMC readiness, a security architecture review, or contact Trawvid Sec.