Vendor apps are everywhere in manufacturing these days. Enterprise Resource Planning (ERP) systems like SAP, Oracle EBS, and Microsoft Dynamics are the backbone of any manufacturing company.
ERPs bring platforms like logistics, procurement portals, warehouse management systems, and EDI integration under one roof. But ERPs don’t always provide the niche service that you need, and third-party vendor integrations can help accommodate your requirements.
However, this is also where failure happens.
Each connection requires an API configuration. Most small or mid-sized vendors with loose security whose API credentials grant deeper access into an organization’s larger ERP environment becomes a risk to the supply chain data protection.
It’s no longer a hypothetical risk. In the first half of 2025, researchers documented a 210% increase in active exploitation of SAP vulnerabilities year-over-year.
In 2025, UK’s largest car manufacturer, Jaguar Land Rover (JLR), had to bring its production to a standstill after a severe cyberattack. It wasn’t just a loss for JLR, but the entire supply chain comprising of 5000 SMBs. The estimated impact on the UK economy was $2.5 billion.
As a result, manufacturing security matters now more than ever. Before we get into the vulnerabilities and how to mitigate them, let’s take a look at the vital data that is exposed because of weak API integrations in the ERP.
Why ERP Integrations Create a Bigger Risk Than Assumed
Manufacturing ERP systems manage more than just customer or employee information.
They deal with vital data like supplier details, on-site inventory, production timelines, bills of materials, pricing strategies, purchase orders, invoices, shipping updates, and more.
When a vendor application is connected to this ecosystem, it serves as another pathway to access that crucial data.
NIST’s guidelines on API security urge for a zero trust framework. It calls for a meaningful distinction between “external” and “internal” callers. It is necessary because any vendor app interacting through your ERP APIs should be regarded as untrustworthy until it verifies its legitimacy with each request.
This is where many manufacturing organizations still struggle. Integrations are frequently approved based on relevance to the business, but end up operating with broader access than anticipated, long-lasting tokens, and insufficient oversight.
ERP API connections expose a range of sensitive information, including:
- Purchase Order and Procurement Data: These are supplier names, pricing, volumes, etc.
- Bill of Materials and Product Specifications: Proprietary design and manufacturing data are a part of this.
- Inventory and Logistics Data: These are inventory stocks, shipment schedules, and distribution routes.
- Financial Data: This includes costs, margins, payment terms, payment details, or contracts.
- Vendor and Client Communication: From detailed notes and briefings to regular updates and progress reports, communications with client and vendors are a part of these.
- Employee and Payroll Data: These depends on the HR module integrations
- Controlled Unclassified Information (CUI): This is crucial for manufacturers with DoW supply chain relationships.
The question is never simply whether your ERP is secure. The question is whether every app that touches your ERP is also secure, and whether its API access is scoped to only what it needs.
To understand where to start with your manufacturing security, you need to first learn about the API vulnerabilities.
What are the API Vulnerabilities in ERP Environments?
Most vulnerabilities in ERP integration come from ordinary implementation mistakes that sit unchecked and untouched for months.
The OWASP API Security Top 10 outlines the categories that are most frequently exploited in practice, and five of these are particularly significant.
Broken Object Level Authorization (BOLA): One of the most common API vulnerabilities, BOLA happens when an API endpoint accepts requests for objects such as records and files without verifying whether the requesting user or application is authorized to access that specific object.
For example, if an authorization logic in your ERP doesn’t restrict an API from accessing purchase order records as per query or function, then there is a chance a compromised vendor credential can expose your entire purchase order history.
Broken Object Property Level Authorization (BOPLA): A BOPLA happens when an API allows users to read or modify sensitive data that they are not authorized to access.
This can happen in two ways – excessive data exposure and mass assignment. Excessive data exposure is when a vendor app needs to send you a certain data such as a delivery update but instead returns the entire order record containing confidential details.
Meanwhile, mass assignment occurs when an API endpoint allows an unauthorized user to modify or delete the value of an object’s property.
Broken Function Level Authorization (BFLA): Where BOLA deals with record-level access, BFLA is concerned with function-level access. A vendor app may be authorized to read inventory data but not to perform inventory adjustments. If the API doesn’t enforce that boundary at the function level, it can perform actions it was never supposed to perform.
For a compromised app or an attacker using its credentials, this can lead to unauthorized manipulation of supply chain transactions, including unauthorized payments.
Long-lived API Keys: Over time, ERP customizations add more integration points. In such an environment, API keys are shared across the manufacturing pipeline, stored in vendor application configs without encryption, and granted broader permissions than the integration requires.
If API keys are not short-lived, rotated, and revocable, they are liable to give unauthorized access. As the ERP sees them as authenticated requests, their activities go unflagged.
Shadow APIs: Shadow APIs stay hidden within the ERP and operate without the knowledge of the IT and manufacturing security. They are APIs that are neither secured nor monitored, essentially opening an attack vector for bad actors.
These APIs may lack multi-factor authentication or have a code with a known vulnerability, all of which can be exploited through the credentials of a compromised vendor.
How Are API Vulnerabilities Impacting Manufacturing Companies?
Manufacturing data breaches due to a compromised third-party does not just leak data. It can delay production, disrupt ordering, and weaken trust across supplier relationships.
The Jaguar Land Rover cyberattack made such an impact that The Bank of England blamed it as one of the reasons for UK’s slow economic growth in 2025.
The data breach was claimed by a hacker group called HELLCAT who specialize in ransomware attacks. They stole hundreds of internal documents and employee data through stolen Jira credentials.
JLR halted production completely for a month and later even extended it just to make sure of every datapoint the HELLCAT breach has touched. Ultimately, it costed the company £50 million per week.
And the impact on JLR’s supply chain was massive. An entire network of manufacturing plants providing parts, materials, and electronics came to a standstill, putting 104,000 jobs at risk.
API attacks in the supply chain do not come from a single-exploit compromise. It is a chain reaction.
A threat actor begins by compromising a vendor’s application and then moves into your ERP. They either use credential stuffing attack to gain unauthorized access through a list of stolen credentials or credential stealing attacks like DDoS to take over an account.
With these credentials, they then probe your ERP’s API endpoints, searching for excessive permissions, exposed functions, and neglected endpoints. This allows them to exfiltrate data or manipulate transactions without triggering any alerts related to authentication or authorization, as they are utilizing valid credentials.
This is the reality for manufacturers running ERP environments with third-party integrations. The perimeter you’ve secured around your ERP is only as strong as the least-secured vendor that has API access to it.
How to Actually Secure ERP API Integration
Many organizations approach this issue by simply protecting the ERP through internal access based on job roles and limiting third-party access. But that is too narrow.
The true objective should be to manage every application and service that interacts with the ERP through APIs. And this encompasses four key points:
1. Define the Integration Based on Specific Business Needs
Permissions must be strictly outlined according to business unit, plant, and warehouse, along with the action type. The distinctions between read, write, and delete should never overlap.
For instance, if a logistics application only requires shipment status updates, it should not have access to sensitive information much less tamper with them.
2. Prioritize Strong Client Authentication
For ERP integrations, long-lived basic auth credentials should be replaced with OAuth 2.0 or certificate-based client authentication.
Oracle’s integration documentation explicitly protects REST APIs with OAuth token-based authentication.
3. Data Masking of Sensitive Data
Data masking hides the original data with random characters and is an API security best practice to protect sensitive information. It is also mentioned in the GDPR and came into effect in 2018.
Dynamic Data Masking (DDM) also falls under this. The process obfuscates data in real-time as it is requested via an API. It typically uses middleware or an API gateway to apply rules based on user roles or access permissions.
4. Implement Authorization at the Object Level
It’s not enough just to verify the app’s authentication.
The ERP API needs to check if that particular app is authorized to access the specific record it’s looking for. It should also filter the returned fields so that the app only receives the data it genuinely requires.
5. Log Every API Interaction as Evidence
Documenting API logs and analyzing them can not only identify the damage cause but also prepare you for the exposed vulnerability in the ERP that can cause damage later.
Keep track of details like who accessed what data and any anomalies that arise during API interactions as per SAP’s recommendations.
6. View Vendor Applications as Distinct Identities Rather Than Shared System Users
Each vendor application should have its own unique service identity, credentials, logging path, and a method for revocation.
That means no shared API keys, no generic integration accounts, and absolutely no permanent credentials that outlast mergers, product changes, or staff turnover.
7. Prioritize API Policy Enforcement Ahead of the ERP
For many manufacturers, the ERP lacks the flexibility to impose every necessary security control effectively on its own.
This is where tools like gateways or policy-aware middleware come into play. They can validate claims, limit access methods, identify anomalies, and create detailed client audit trails before requests even reach the ERP data layer.
8. Limit or Shorten API Token Lifetimes
Long-lived API tokens can spell disaster for your ERP security. It can turn a small leak into a compromised breach path that may take months to detect.
Using Refresh Tokens, implementing rotation, and ensuring your client-side code is configured to catch expired tokens could be the way forward.
What a Proper ERP API Security Assessment Entails
A manual penetration test for ERP API integrations is different from a standard web application pentest. It demands a deep understanding of the ERP platform, a solid grasp of API security practices, and insight into supply chain data protection.
Let’s check how the evaluation typically unfolds
1. API Discovery and Inventory
Before any testing, it is essential to compile an exhaustive list of every API integration still active in the ERP.
This means identifying each vendor application linked to the ERP and noting which endpoints each integration access. This includes verifying the vendor security and the assigned permission levels.
2. Authorization Testing (BOLA and BFLA)
Each integration undergoes tests to ensure that both object-level and function-level authorization is correctly enforced at the API level. This involves creating real-world attack scenarios and evaluating whether the API properly maintains boundaries.
BOLA testing determines whether an API endpoint will serve records that it shouldn’t. Suppose a tester uses the logistics app’s credentials to request objects that should only be accessible to the procurement app.
If the API returns those records without rejecting the request, then the boundary has failed. In a manufacturing environment, a BOLA failure in an ERP procurement module means a compromised logistics vendor.
In BFLA testing, the full set of API functions, not just the functions the vendor app uses, is mapped. The tester systematically attempts write, update, and delete operations using each integration’s credentials.
In manufacturing, a BFLA failure means an attacker with a compromised vendor credential can manipulate ERP transactions. Meaning financial data regarding supplier pricing and purchase orders is no longer safe.
3. Data Exposure Assessment
For each active integration, the assessment involves mapping out the actual data returned by each API endpoint against the expected data that the integration was supposed to return.
The key objective here is to detect whether integrations are potentially handling data that falls outside their intended scope.
4. Authentication and Credential Review
The review process evaluates various things concerning API security, such as the age of API keys, policies for rotating them, and how credentials are stored.
OAuth implementations are scrutinized for common weaknesses, including algorithm confusion, missing claim validation, token scope, and enforcement of expiry.
5. Business Logic Testing
This step is where we examine every integration that has engaged with vital ERP functions such as procurement, inventory, and payments for possible logical manipulations.
This entails testing if workflows can be triggered out of order, if approval processes can be circumvented, and if pricing or quantity inputs can be altered, basically checking for scenarios with unexpected outcomes.
6. Orphaned and Undocumented Endpoint Discovery
A thorough examination will reveal endpoints that respond to requests but don’t show up in existing integration documentation.
These discovered endpoints are then tested to assess their permission levels and determine if they are still vulnerable, even if the related integration is inactive.
The CMMC and NIST 800-171 Perspective
For manufacturers involved with the Department of War (DoW) supply chain, ERP API integrations must follow government compliance, elevating this from a mere security concern to an audit requirement.
CMMC Level 2 aligns with all 110 controls laid out in NIST SP 800-171 and mandates restrictions, monitoring, and enforcement regarding third-party access to systems managing Controlled Unclassified Information (CUI). If an ERP integration interacts with procurement data or supplier information, it essentially falls under CMMC requirements.
For manufacturers sharing CUI through integrations, your compliance duties extend to those data transactions as well. Unexamined vendor API connections often become a common finding during C3PAO assessments.
Organizations that haven’t mapped their ERP API integrations against CUI data flows can face issues. Conducting an ERP API security assessment will address both the scope concerns and control questions at the same time.
How KLEAP can help
At KLEAP, we focus on providing manual penetration testing specifically for manufacturing settings, including thorough assessments of ERP API integrations that cover all the necessary aspects.
We don’t rely on automated scans masquerading as penetration tests.
Each engagement is led by a skilled security expert who has a deep understanding of both ERP platform architecture and API security methods. We carefully evaluate the authorization logic, examine data exposure risks, and identify any orphaned endpoints.
Our detailed report presents each finding alongside proof-of-concept evidence and clear remediation steps.
For manufacturers working towards CMMC compliance, we align our findings directly with the NIST 800-171 control families that your C3PAO assessor will need to review. This means our penetration test not only serves as a remediation roadmap but also as audit evidence through proper documentation.
If you’re looking for an accurate understanding of what your vendor app integrations can access, KLEAP can provide you with a detailed scope in just one call.
