Legacy ERP often remains the "heart" of an enterprise: it handles finances, procurement, production, logistics, and management reporting. At the same time, such systems often lack support for modern multi-factor authentication, SAML/OIDC, contextual access policies, or sufficiently granular privilege control. Completely rewriting the code or replacing the ERP can be too risky for business continuity, so a CISO needs an intermediate, yet manageable, path to risk reduction.
The threat landscape makes this task practical rather than theoretical. The ENISA Threat Landscape 2025 identifies phishing as the leading initial access vector. In the same reporting period, 53.7% of organizations affected by cyberattacks belonged to essential entities within the scope of NIS2. For industry, critical infrastructure, and large enterprise organizations, this means that if a user account is compromised, the ERP must not remain an open target for direct access and lateral movement.
The Zero Trust approach in this scenario does not mean that a legacy ERP suddenly becomes a "Zero Trust system." It is more accurate to speak of a security perimeter around it: an identity-aware proxy for web access, Privileged Access Management for administrative and service accounts, and network microsegmentation that allows only necessary traffic between the ERP, the database, integration gateways, and administrative workstations.
Why legacy ERP is a convenient target for lateral movement
A typical problem with legacy ERP is not a single vulnerability, but a combination of architectural limitations. The system may be stable in terms of business functions but lack mechanisms that are considered basic for access control today.
- Outdated authentication. Some ERP systems rely on local logins and passwords and do not support modern MFA scenarios or identity federation without an additional layer.
- Excessive privileges. If roles and rights have been formed over years without regular review, users and technical accounts may have broader access than is required for their current tasks.
- Direct network access. In flat or poorly segmented networks, a compromised workstation can see ERP servers, databases, or administrative interfaces directly.
- Service accounts. Integrations between the ERP, database, and related systems often operate via long-lived technical accounts that are difficult to change quickly without disrupting processes.
The Cisco Cybersecurity Readiness Index 2025, based on a double-blind survey of 8,000 cybersecurity business leaders across 30 markets, evaluates organizational readiness across five pillars: Identity Intelligence, Machine Trustworthiness, Network Resilience, Cloud Reinforcement, and AI Fortification. For legacy ERP, the first three are particularly practical: who is connecting, from what environment, via which channel, and with what privileges.
Identity-Aware Proxy: MFA before entering the ERP
An Identity-Aware Proxy is placed in front of a web-oriented ERP and intercepts the user's request before it reaches the system's login page. In a basic scenario, the IAP redirects the user to the corporate Identity Provider, where MFA and access policies are applied. Only after a successful verification does the proxy forward the request to the ERP.
This is useful precisely when an ERP cannot be quickly updated to support modern authentication protocols. The application code remains unchanged, but the entry point is brought under the control of a modern identity layer. For users, this may appear as an additional login step, while for the security team, it provides the ability to centrally apply MFA policies and revoke access without interfering with the ERP.
An important limitation: IAP works well for HTTP/HTTPS access but does not inherently protect the database, thick clients, service protocols, or direct integrations. Therefore, it cannot be considered a sole control. Its task is to eliminate unauthorized web access and make authentication manageable from the outside.
PAM: Controlling administrators and service accounts
The second layer is Privileged Access Management. If the IAP answers the question "who can reach the ERP interface," then PAM answers the question "who manages the servers, databases, and technical accounts, and how."
For legacy ERP, PAM typically serves three practical tasks:
- Privileged credential vault. Administrators should not work with shared static passwords for ERP servers or DBMS.
- Service account rotation. A PAM vault can be used to rotate credentials for service accounts connecting to the ERP database, reducing the risk of leaking long-lived or hardcoded passwords.
- Session control. Administrative access to ERP servers should be conducted through a PAM gateway with logging and, depending on organizational policy, session recording.
This layer is especially important for scenarios where the ERP is integrated with many internal systems. If a service account has excessive rights or its password has not been changed in a long time, the compromise of a single integration could open access to critical data. PAM does not eliminate the need to review rights within the ERP itself, but it provides control over the most high-risk privileges outside of its code.
Microsegmentation: ERP should see only what is necessary
The third layer is microsegmentation. Its goal is to ensure that even after a workstation or internal server is compromised, an attacker cannot move freely toward the ERP and its database.
A practical minimum for an ERP perimeter looks like this:
- The ERP database server accepts requests only from authorized ERP application servers.
- ERP application servers accept web requests only from the Identity-Aware Proxy and designated integration gateways.
- Administrative protocols like SSH or RDP are available only from PAM servers or specific managed administrative workstations.
- Integrations with other systems are defined as specific allowed flows, rather than broad access between network segments.
The biggest risk during microsegmentation is accidentally breaking legitimate business processes. Therefore, before implementing rules, it is necessary to map actual flows: which systems connect to the ERP, which ports and protocols are used, which integrations run on a schedule, and which operate in real-time. Without this, microsegmentation turns into a series of emergency exceptions that quickly destroy the initial security model.
API and machine-to-machine access without rewriting the core
A separate risk area is the integration between legacy ERP and other internal systems. If the ERP has an outdated API or exchanges data via service channels, access verification should be moved to an integration gateway. Such a gateway can verify tokens, certificates, or other indicators of request trust before passing it to the legacy system.
As a conceptual analogy, the FCC in its materials regarding STIR/SHAKEN describes the combination of a technical authentication/verification process with certificate governance to support trust. For enterprise integrations, this is not a direct instruction for ERP, but it well illustrates the principle: trust should rely not on network location, but on verifiable identity, certificate management, and policy control.
Break-glass: How not to stop business if the identity layer fails
An additional security perimeter should not become a single point of failure. If the IdP, IAP, or PAM are unavailable, the enterprise must have a pre-defined break-glass procedure. Its purpose is not to "open everything," but to provide limited, controlled, and audited emergency access.
A practical break-glass model for ERP should include:
- Clearly defined owners of the decision to activate emergency access.
- A backup path, such as a secure physical console connection or an isolated service segment.
- Separate accounts or keys that are not used in daily operations.
- Mandatory logging of the activation event, time, user, and actions performed.
- A procedure for returning to normal operations after the identity layer is restored.
Break-glass procedures must be tested just like backups or disaster recovery plans. An untested procedure often turns out to be either non-functional or too broad in terms of access.
Implementation methodology without stopping the ERP
To avoid disrupting business processes, the security perimeter should be deployed in stages. For risk management, the Govern, Map, Measure, Manage logic—which NIST AI RMF 1.0 applies to AI risk management—is useful; in the case of legacy ERP, it can be used as a general discipline for managed implementation.
- Govern. Identify ERP risk owners: CISO, CIO, business process owners, ERP administrators, and the network and IAM teams. Define who approves access policies and exceptions.
- Map. Describe users, roles, integrations, service accounts, network flows, administrative routes, and dependencies on related systems.
- Measure. Test IAP, PAM, and segmentation rules in a test or pilot environment. Measure not only technical functionality but also the impact on business processes.
- Manage. Gradually transition user groups and integrations to the new access model, starting with less critical scenarios. All exceptions must have an owner, a review period, and a justification.
Matrix of security tools for legacy ERP
| Tool | Where applied | What it limits | Key limitation |
|---|---|---|---|
| Identity-Aware Proxy | Before the ERP web interface | Access without MFA or without identity policy verification | Does not cover direct database access, thick clients, or non-web protocols |
| Privileged Access Management | Administrative sessions, servers, DBMS, service accounts | Uncontrolled use of privileged passwords and long-lived technical accounts | Requires integration with directories, support processes, and break-glass procedures |
| Microsegmentation | Network flows between ERP, database, gateways, and admin nodes | Lateral movement and direct connections from unauthorized segments | Requires precise flow mapping; otherwise, legitimate integrations may be broken |
| Integration gateway | API and machine-to-machine interaction | Unverified requests to legacy ERP interfaces | Does not replace vulnerability patching in the ERP itself or internal rights control |
Where the integration team role is appropriate
In projects of this type, the main complexity is usually not in installing a specific tool, but in the intersection of security, networking, IAM, databases, and business processes. The goal is not to rewrite the ERP, but to properly "wrap" it: describe the flows, move authentication to an external layer, close direct network routes, implement PAM, and leave controlled emergency access.
Within Intecracy Group, such tasks can be performed as architectural and integration projects; Softengi is suitable to be engaged as a custom development and system integration team. If the enterprise is simultaneously creating new portals, dashboards, or an integration layer around a legacy ERP, the platform foundation can be UnityBase—a joint development of Intecracy Group companies, where InBase is a key, but not the only, developer. In this context, what is relevant are not marketing promises, but specific platform mechanisms: generated REST API, RBAC/RLS, audit trail, and for commercial editions—specifically OpenID Connect/OAuth2 and additional access control capabilities depending on the edition.
The main conclusion: IAP, PAM, and microsegmentation do not cancel ERP patching, OS and DBMS hardening, or planned modernization. However, they allow for reducing the attack surface around a system that cannot be quickly replaced, making access to it verifiable, limited, and audited right now.
FAQ
Does the legacy ERP itself become Zero Trust compliant after implementing proxy and microsegmentation?
No. The external perimeter does not change the internal architecture of the ERP and does not automatically make it Zero Trust compliant. It shifts some controls to the outside: identity verification, network route restriction, privileged session control, and access auditing.
How do I set up break-glass access to the ERP in case of IdP or proxy failure?
You need to pre-define a backup access path, for example, via a secure physical console or an isolated service segment. Activation must be role-restricted, logged, and followed by a return to the standard model after the identity layer is restored.
How can I protect integrations between legacy ERP and internal systems without rewriting code?
A practical approach is to move control to an integration gateway: define allowed flows, verify the identity of the system or service account, restrict network routes via microsegmentation, and manage credentials via PAM.