Direct access turns supplier credentials into high-risk delegated identities, especially when those accounts can query large record sets or operate across multiple systems. The failure is usually scope, not authentication. If behavioural baselines, narrow role design, and rapid disablement are absent, a single valid account can expose data at scale before anyone notices.
Why Third-Party Direct Access Breaks Data Boundaries
When suppliers can query customer or ERP data directly, the trust model changes from controlled delegation to shared exposure. The real break is not login success; it is that a valid third-party account can reach records, business processes, and audit trails without a strong enough boundary around what it should see or do. That creates delegated identity risk, but also governance and containment risk across procurement, finance, and support operations.
In practice, direct access often starts as a convenience feature and becomes an invisible data plane for vendors, integrators, and service providers. Once those accounts are allowed broad reads, exports, or cross-system actions, the organisation loses the ability to separate legitimate supplier activity from overreach. NHI Mgmt Group research notes that 92% of organisations expose NHIs to third parties, which makes supplier access a common concentration point rather than an edge case. In practice, many security teams discover the scope problem only after the account has already been used to pull far more data than the business intended.
How the Failure Shows Up in ERP and Customer Systems
Direct third-party access breaks down in a few predictable ways. The account may be authenticated correctly, yet still be authorised too broadly, tied to a static role that never shrinks, or allowed to operate across environments that were never meant to share trust. In ERP systems, that can mean access to invoices, payroll-adjacent data, vendor master records, or transaction history. In customer platforms, it can mean bulk exports, account lookup abuse, or visibility into records that should have been segmented by region, product line, or support case.
The practical problem is that these accounts are often created for workflow efficiency, then left in place because disabling them would slow operations. That makes lifecycle control as important as initial provisioning. A strong design usually combines narrow role assignment, time-bound access, explicit approval for elevated queries, and monitoring that can distinguish normal supplier behaviour from unusual retrieval patterns. The objective is not merely to block obvious misuse; it is to make direct access proportional to the business task and revocable without delay.
Useful control patterns include:
- limit third-party accounts to a single system or bounded dataset
- separate read-only support access from export or admin functions
- require explicit expiry and periodic recertification for every vendor account
- log query volume, record type, and unusual access timing
- disable cross-environment reuse of the same supplier identity
This guidance tends to break down where ERP customisations, legacy integrations, or shared service accounts prevent reliable scoping because the organisation cannot enforce separation at the identity or data layer.
Common Edge Cases in Supplier and ERP Access
Tighter supplier access usually increases operational friction, so organisations have to balance business continuity against blast-radius reduction. That tradeoff becomes sharp when vendors need to troubleshoot live incidents, reconcile transactions, or support multiple business units under one contract.
One common edge case is “read-only” access that is still dangerous because the dataset itself is sensitive or highly correlatable. Another is delegated support access that looks temporary but is effectively permanent because teams reuse the same account for convenience. Best practice is evolving, but current guidance suggests treating supplier accounts as high-risk by default whenever they can see customer data, financial records, or system-wide ERP objects. The most important question is whether the access can be bounded to a purpose, not whether the vendor is trusted.
Where possible, organisations should avoid making supplier identities the owner of broad business access paths. If a third party must interact directly with data, the access model should be narrow enough that a single credential cannot become a hidden exception channel for the entire environment. That is especially important when the same account can be used by multiple people inside the supplier organisation, because attribution becomes weak and revocation becomes harder to prove.
Risk and Threat Considerations
Third-party direct access creates a concentrated exposure point: one supplier identity can become a broad data extraction path if its scope is too large or its activity is not monitored. The risk is amplified when the account can query high-value records, move across systems, or persist beyond the original business need.
Failure mechanism: Over-broad authorisation, static credentials, and weak behavioural monitoring let a valid external account perform legitimate-looking bulk retrieval or cross-system access without triggering immediate suspicion. If the account is shared, compromised, or reused, defenders may lose attribution and containment at the same time.
Impact: Customer confidentiality, ERP integrity, and audit reliability can all degrade at once. The organisation may face large-scale data exposure, unauthorised exports, difficult revocation, and prolonged uncertainty about what the third party actually accessed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI lifecycle — Lifecycle Management | Third-party accounts are delegated NHIs that need tight lifecycle control and revocation. |
| NHI authorization — Authorization and Least Privilege | Direct ERP and customer access is primarily a scope and privilege problem. | |
| NHI visibility — Discovery and Monitoring | Bulk retrieval and cross-system access need monitoring to detect misuse or overreach. | |
| Recommendation — Enforce expiry, rotation, and rapid offboarding for supplier identities with data access. Restrict each third-party identity to the minimum dataset and action set required. Monitor supplier account behaviour for unusual volume, timing, and cross-system access. | ||
| CIS Controls v8 | 5 — Account Management | Third-party accounts require controlled provisioning, review, and removal. |
| 6 — Access Control Management | The break is excessive access, so scoped access control is the core safeguard. | |
| Recommendation — Inventory, review, and disable supplier accounts that no longer have a valid business need. Apply least privilege and separate read, export, and administrative permissions. | ||
| NIST CSF 2.0 | PR.AA — Identity Management, Authentication, and Access Control | Supplier access to customer and ERP data is an identity and access governance issue. |
| Recommendation — Define and enforce access boundaries for third-party identities before granting data reach. | ||
Practitioner Guidance
What to prioritise: Treat every third-party account with data access as a scoped trust exception, not a routine user. Prioritise datasets with customer, financial, or operational records because those are the places where overreach becomes material fastest.
Decision rule: If the supplier account can read more than it needs for a named task, reduce scope before you debate whether the account is “trusted.” If the account can export, query broadly, or cross systems, treat it as a high-consequence identity until proven otherwise.
What to verify: Confirm who can request the account, who can approve it, what data objects it can reach, and how quickly it can be disabled. The key test is whether revocation is operationally real, not whether an owner exists on paper.
Common mistake: Teams often focus on authentication quality and ignore dataset scope. That leaves a perfectly valid account with the ability to harvest data at a scale the business never intended.
Practitioner takeaway: The decisive control is not whether the supplier is known, but whether the supplier’s access is narrow enough that compromise, misuse, or simple overreach stays containable.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
