What is third-party risk for manufacturers?

Key takeaways

• Third-party risk is the security posture of everyone who has access to the manufacturer's environment, data, or operations.
• For mid-market manufacturers, the most material third parties are usually OT vendors with remote access, MSP/MSSP providers, financial institutions, and tier-1 customers who hold engineering data.
• A generic third-party risk program (questionnaires, scoring tools, annual review) catches some risk but misses manufacturing-specific failure modes: OT vendor access, on-site contractor flow, and operational data exposure to tier-1 customers.
• The right shape for a mid-market manufacturer is small and practical: 30 to 60 named vendors, criticality-rated, with focused review depth on the top ten.
• ARG audits third-party exposure as part of the integrated on-site engagement.

What does third-party risk look like for a manufacturer specifically?

A mid-market manufacturer's third-party landscape is wider than a typical service business's. The categories that matter:

1. OT and equipment vendors. Companies that sold and support the machines on the plant floor. They have specialized knowledge, remote access, and (sometimes) physical visits scheduled regularly. They are also the dominant operational dependency: when a critical machine fails, the vendor is who restores it.

2. IT vendors and managed-service providers. Email and productivity providers (Microsoft, Google), endpoint vendors, network equipment vendors, identity-provider vendors, MSP and MSSP partners. The traditional IT supply chain.

3. Tier-1 customers holding the manufacturer's data. Customers (especially primes and large OEMs) often hold the manufacturer's engineering files, BoMs, quality data, and process specifications. A compromise of the customer reaches the manufacturer's data.

4. Sub-tier suppliers. Companies that supply materials and components to the manufacturer. They handle the manufacturer's purchase orders, quality specifications, and (sometimes) intellectual property when the manufacturer is the customer.

5. Financial and professional services. Banks, insurance carriers, accountants, attorneys, payroll providers. They hold financial data, employee data, and (depending on the service) operational data.

6. On-site contractors. Maintenance, cleaning, security guards, food service, trucking, freight. They have physical access during contracted windows; some have IT access (badge systems, time clocks, vendor portals).

7. Software vendors for product-embedded software. For manufacturers that ship products with embedded software (industrial equipment, IoT devices, automotive subsystems), the embedded-software vendors are part of the product's security posture and therefore part of the manufacturer's third-party risk.

A complete inventory crosses all seven categories. Most mid-market manufacturers, when first inventoried, find that their understanding of "vendors" covers two or three of these and misses the rest.

The three categories: vendors, primes, and remote-access partners

For prioritization, the seven categories above collapse into three risk-driven groupings.

1. Remote-access partners. Any third party with logical access into the manufacturer's environment. OT vendors with VPN to PLC programming systems, MSPs with admin access, SaaS platforms with broad scopes, software-as-a-service providers integrated into operations. This group is the highest-risk category because a compromise produces direct access. See What is the IT/OT convergence problem?.

2. Data-holding parties. Third parties that hold the manufacturer's data outside the manufacturer's environment. Tier-1 customers with CAD files, suppliers with BoMs, financial institutions with payment data, professional services with sensitive correspondence. A breach at the third party is a breach of the manufacturer's data.

3. Operational dependencies without access. Third parties whose compromise would disrupt operations even if they have no logical access to the manufacturer's environment. Critical material suppliers, freight carriers, utility providers. The risk is operational disruption, not data exposure.

The three categories warrant different control sets. Remote-access partners need access governance. Data-holding parties need contract terms (breach notification, data-handling specifications, audit rights). Operational dependencies need continuity planning. A program that applies the same questionnaire to all three is doing one of them correctly at best.

Why generic third-party risk programs miss manufacturing-specific failure modes

Three reasons most off-the-shelf third-party risk approaches under-serve manufacturers.

1. They focus on data, not access. Generic TPRM tools are built around vendors that handle data (cloud providers, SaaS, professional services). They under-represent vendors who have direct logical or physical access to operational systems. For a manufacturer, the OT vendor with VPN to a PLC is higher-risk than the customer-relationship-management SaaS, but generic tools score them in the wrong order.
2. They miss physical-flow vendors. Cleaning services, maintenance contractors, freight providers, and on-site trade contractors have physical access during their visits. They are categorically absent from most TPRM programs but represent material risk. See What is a physical security audit?.
3. They use IT-flavored questionnaires. Questionnaires written for IT vendors do not surface OT-relevant risk: vendor remote-access mechanisms, vendor-side authentication on operational systems, vendor employee turnover affecting credentialed access. A questionnaire that asks about SOC 2 compliance is useful for IT vendors and uninformative for OT vendors who do not pursue SOC 2.

The fix is not to throw out generic TPRM frameworks; it is to extend them with manufacturing-specific categories and questions. The base structure is fine; the depth and specifics need translation.

Examples of third-party incidents in industrial settings

What ARG sees and what the public record shows:

• Vendor-mailbox BEC. A critical-vendor's mailbox is compromised. Subsequent invoices from the legitimate sender route payment to a new bank account. The manufacturer's AP processes the wire because the email is from the genuine sender. See What is business email compromise (BEC)?.
• OT vendor remote-access compromise. A regional OT vendor's infrastructure is compromised. The attacker reaches multiple customer manufacturers through the vendor's pre-existing remote-access tools. None of the manufacturers' perimeters see anything unusual.
• MSP breach affecting multiple downstream manufacturers. An MSP serving small manufacturers is breached; the attacker uses the MSP's tools to deploy ransomware to its customers (Kaseya-style pattern). The customers' direct security investment is irrelevant; the MSP's compromise is the attack path.
• SaaS-provider compromise leaking engineering data. A SaaS provider used for engineering collaboration is breached. The manufacturer's CAD files held in the provider become accessible to attackers.
• Tier-1 customer compromise exposing supplier data. A large customer is breached; the supplier's design files, BoMs, and pricing information held by the customer become exposed.
• On-site contractor as physical access path. A cleaning contractor or trade contractor is unwittingly used as a physical access path during a pretexted entry. The contractor is not malicious; the pretext rides their normal access.
• Embedded-software vendor pushing compromised update. For manufacturers shipping products with embedded software, an embedded-software vendor's compromise reaches the manufacturer's products and (downstream) the manufacturer's customers.

The pattern: third-party compromise is the access path more often than direct attack. The manufacturer's perimeter does not matter when the attacker is already inside the boundary through a vendor's connection.

How to build a lightweight third-party risk program for a 50 to 500 person manufacturer

A practical sequence for a mid-market manufacturer building third-party risk management from minimal starting state.

1. Build the vendor inventory. All third parties listed: vendor name, contact, contract value, access type (logical, physical, none), data held, criticality rating (high, medium, low). Most facilities discover vendors they did not know about in this step.
2. Score by criticality. Criticality is a combination of impact (what happens if this vendor is compromised) and likelihood (how exposed is this vendor). Top ten vendors get focused review depth; the rest get a baseline questionnaire and contract review.
3. Tier the review depth. Tier 1 (critical, top ten): named-account access governance, MFA verification, breach notification clauses, contract security terms, annual reassessment. Tier 2: questionnaire, contract security terms, annual reassessment. Tier 3: contract security terms, biennial check-in.
4. Update contracts for new vendors and at renewal. Standard security clauses (breach notification within X hours, encryption requirements, data handling, audit rights). The contract is the leverage; without it, the questionnaire is informational.
5. Implement access governance. All vendor logical access through named accounts; MFA; session recording for high-risk access; time-bounded permissions. See What is privileged access management (PAM)?.
6. Monitor for vendor-side events. Public breach disclosures involving vendors are tracked; affected vendors contacted to confirm scope and remediation.
7. Plan for vendor compromise scenarios. Incident response playbooks include scenarios: critical OT vendor compromised, MSP compromised, financial-services provider compromised. The playbook addresses notification, containment, and recovery without depending on the vendor's response.
8. Coordinate with compliance and insurance. The third-party risk program supports CMMC, NIST SP 800-171, NIST CSF 2.0, and cyber insurance underwriting evidence requirements.

The program for a 200-person manufacturer can be operated by one IT lead with executive sponsor support. It does not require a dedicated TPRM team.

Best practices for vendor onboarding and ongoing monitoring

1. Security review before contract signing. New vendors are scoped for access type, data class, and criticality during the procurement cycle. The security review happens before the contract is finalized, so security terms can be negotiated.
2. Standard security clauses in every contract. Breach notification, data handling, audit rights, MFA on access, named-account requirements, employee turnover notification. The clauses are baseline; specific vendors get tighter terms where warranted.
3. Named-account access for all vendors. Shared "vendor" accounts replaced. Access logged to named accounts. Vendor employees who depart are removed promptly.
4. MFA on vendor access. Every vendor account with logical access has MFA enforced. Vendors without MFA capability do not get logical access until they have it.
5. Session recording for high-risk vendor access. OT vendor remote access, admin-level access, sensitive-data access. Recording is part of the access path, not optional.
6. Annual security reassessment for top-tier vendors. Re-questionnaire, contract review, access review. The reassessment is targeted at what could have changed since the last review.
7. Continuous public-breach monitoring. Services like cyber threat intelligence feeds, security ratings services, or simple Google Alerts on vendor names flag public breaches. Internal process responds to flagged events.
8. Documented escalation for vendor compromise. Who is called when a vendor is breached, what containment actions run, who notifies leadership, when notification flows to insurance. The playbook exists before the event.

Third-party risk FAQs

Do I need a TPRM tool, or can spreadsheets work?

For a 50 to 500 person manufacturer with fewer than 50 critical third parties, a well-maintained spreadsheet plus a few standard questionnaires is sufficient. Above that count, a TPRM tool starts paying back through workflow and data structure. The point is the process, not the tool; a tool without process produces empty fields, and a spreadsheet with process produces real risk management.

How often should vendors be reassessed?

Annual for most vendors, semi-annual for critical vendors, immediately after any material event (breach disclosure, contract change, ownership change). The reassessment is not a rerun of the onboarding questionnaire; it focuses on what has changed since the last review and whether the original risk rating still holds.

Who owns third-party risk in a mid-market company?

Usually a small group: the IT lead, the procurement or operations lead, and the executive sponsor for security. In larger mid-market organizations, the function may be formalized; in smaller ones, it is a shared responsibility. What matters is named accountability and a documented escalation path when a third party fails review.

How does cyber insurance evaluate third-party risk?

Underwriters increasingly ask for documented third-party risk management: vendor inventory with criticality rating, vendor security review process, breach notification clauses in contracts, and incident response procedures for vendor compromise. The absence of a documented program is a premium driver and, in some markets, a coverage limitation. See What is cyber insurance underwriting?.

How ARG audits third-party exposure on engagement

Third-party risk is part of ARG's integrated on-site audit. The work runs alongside the physical security audit, the OT security audit, and the supply chain attack analysis.

The audit is conducted by David Ashby with digital-side analysis from James Wall on the access-governance portions. The work covers:

• Vendor inventory. Built from procurement records, OT vendor management documentation, IT vendor contracts, and SaaS subscriptions. Cross-checked against actual observed vendor presence on site and in the network.
• Access mapping. For each vendor with logical access, the path through the perimeter, the authentication mechanism, the session logging, and the time-bounding (or absence thereof).
• Physical-flow inventory. Cleaning, maintenance, trade-contractor, and freight third parties with physical access. Their scheduled windows, escort policies, and verification procedures.
• Data-holding inventory. Customers, suppliers, and service providers who hold the manufacturer's data outside the manufacturer's environment. Contract terms, breach notification clauses, audit rights.
• Contract review (high-impact vendors). Security clauses, breach notification timelines, data-handling provisions, audit rights. Gaps flagged for renegotiation at renewal.

Where the engagement permits, controlled exercises validate specific third-party-related attack paths: vendor-impersonation pretexts at the gate and over the phone, contractor-pretext entries during normal contractor-flow windows, and (digitally) BEC-style emails from vendor look-alike domains. See What is pretexting? and What is business email compromise (BEC)?.

Findings consolidate into the engagement report with mapping to NIST CSF 2.0, NIST SP 800-171, and CMMC requirements. The remediation backlog prioritizes named-account access, vendor-side MFA verification, breach notification clauses, and physical-flow governance. Continuous monitoring catches changes in vendor risk posture between on-site engagements.

Apply as a founding client or see how the engagement works for the full delivery cycle.