Since 6 December 2025, Germany's NIS2 implementation act has been in force and is enforced by the Federal Office for Information Security (BSI). Around 29,500 companies now fall under BSI oversight, up from roughly 4,500 before (BSI). Anyone breaching the new duties risks fines of up to 10 million euro or 2 percent of global annual turnover (NIS2 implementation act). For trading and industrial companies with a connected online shop, this puts the spotlight on exactly the connections that used to run in the background: the APIs between shop, ERP system and inventory management. Order, customer, price and stock data flow across these interfaces -- and this is where the attack surface that NIS2 addresses arises. This article maps the new duties concretely onto ERP-to-shop interfaces and shows, in five steps, how an existing connection is hardened to NIS2 standards: from inventory through encryption and authentication to monitoring and supply-chain evidence.
What NIS2 Means for the ERP-to-Shop Interface
NIS2 is the second EU directive on network and information security. Germany transposed it into national law with the NIS2 implementation act, in force since 6 December 2025 without a transition period (BSI). A company is affected if it meets three criteria: membership of one of the regulated sectors, at least 50 employees or more than 10 million euro in annual turnover, and classification as an essential or important entity under the BSI Act (BSI). Many wholesalers, manufacturers and retailers with an e-commerce connection fall under this oversight for the first time without immediately realizing it.
The core of the duties sits in Section 30 of the BSI Act: affected entities must take appropriate technical and organizational measures to manage the risks to their network and information systems (BSI). These explicitly include risk analysis, access control, multi-factor authentication, cryptography and encryption, and supply-chain security (BSI). An ERP-to-shop interface is such a network and information system: it processes business-critical data and is reachable from outside. The same standard therefore applies to it as to the ERP or the shop itself.
| Characteristic | Essential entity | Important entity |
|---|---|---|
| Size (guideline) | from 250 employees or over 50m euro turnover | from 50 employees or over 10m euro turnover |
| BSI supervision | proactive, including audits without cause | reactive, after an incident or specific tip-off |
| Fine range | up to 10m euro or 2% of global turnover | up to 7m euro or 1.4% of global turnover |
| Registration with the BSI | mandatory | mandatory |
| Incident reporting | 24 h / 72 h / 1 month | 24 h / 72 h / 1 month |
Why the interface counts, not just the ERP
Newly regulated entities must also register with the BSI within three months and provide contact details and public IP ranges (BSI). This automatically raises the question of which interfaces are reachable from outside at all -- a question that cannot be answered without a complete interface inventory.
The Risk of Old, Undocumented ERP Connections
The greatest danger rarely comes from the newly built interface, but from the old one no one keeps in mind. Over the years, point-to-point connections, import scripts and extra endpoints grow between shop and ERP, created once for a migration or a special project. Our article on migrating legacy ERP systems shows how deep such legacy runs. OWASP lists exactly this issue as its own risk: API9:2023 Improper Inventory Management describes outdated, undocumented or forgotten endpoints that remain reachable (OWASP).
The most common API risk of all is broken object level authorization. It has held first place in the OWASP API Security Top 10 since 2019 and again in the 2023 edition (OWASP). An attacker manipulates the ID of an object in the request -- for example an order or customer number -- and gains access to other people's records because the interface does not check authorization per object (OWASP). Older ERP connections that simply trust every ID passed to them are particularly vulnerable to this.
An interface no one documents any more is not a residual risk but the most likely entry point. NIS2 forces us to finally make these forgotten connections visible.
- Forgotten endpoints: test and legacy endpoints from early project phases keep running without current protection.
- Static credentials: API keys or Basic-Auth passwords hard-coded in the source and never rotated for years.
- Missing object checks: the interface returns records solely by the ID passed to it, without verifying authorization.
- Unencrypted routes: internal connections still running in plaintext inside the data center because they were deemed trusted.
- No logging: access is not logged, so a data leak goes unnoticed and cannot be reconstructed after an incident.
Static keys in the code are the core problem
The economic dimension is substantial: 87 percent of all German companies were recently victims of data theft, industrial espionage or sabotage (Bitkom). The annual total damage to the German economy stands at 289.2 billion euro, of which around 70 percent is attributable to cyberattacks (Bitkom). NIS2 is therefore less a bureaucratic exercise than the regulatory answer to a real, measurable threat landscape.
Step 1: Inventory of All Interfaces
You can only secure what you know about. The first step is therefore a complete inventory of all interfaces between shop, ERP and adjacent systems. OWASP explicitly names a missing interface inventory as its own risk and recommends recording every API version and endpoint and retiring old versions in a controlled way (OWASP). Our article on API versioning for long-lived interfaces explains how to keep and retire version states cleanly.
A solid inventory captures more than just the URL per interface. It documents which data classes flow, how authentication works, who operates the connection and what version and patch state it runs on. Only this overview makes the risk of each connection assessable and forms the basis for the documentation required later towards the BSI.
Endpoints and versions
Every reachable route with method, version and purpose -- including the legacy endpoints no one mentions in daily operations any more.
Authentication methods
Record per interface whether an API key, Basic-Auth, OAuth or mTLS is in use -- weak methods become visible immediately.
Data classes
Which data flows: personal customer data, prices, stock levels or payment information. This determines the level of protection needed.
Operator and location
Who operates the interface, in which data center it runs and whether external service providers are involved.
Version and patch state
Which libraries and runtimes are in use and when they were last updated -- the basis for vulnerability management.
Ownership
A named contact per interface, so it is clear in an incident who has to act and report.
Step 2: End-to-End Encryption
Section 30(2) no. 8 of the BSI Act prescribes the use of cryptography and, where appropriate, encryption (BSI). For an ERP-to-shop interface this means: every connection -- from the browser to the ERP and back -- runs over current Transport Layer Security, typically TLS 1.3. The key word is end-to-end. It is not enough to encrypt only the external connection to the shop and leave the internal routes between middleware and ERP in plaintext because they are considered trusted.
The zero-trust principle no longer recognizes a trusted internal network: every connection is encrypted and every caller authenticated, regardless of whether it sits inside or outside the data center. In practice, the middleware becomes the central place where TLS termination, certificate management and key rotation are bundled and enforced consistently -- rather than being repeated in every point-to-point connection.
Encryption is more than HTTPS at the outer edge
Step 3: Authentication with OAuth 2.0, OIDC and mTLS
Static API keys and Basic-Auth are among the most common weaknesses of old connections. OWASP lists broken authentication as API2:2023 in second place of the API Security Top 10 (OWASP). The standard for modern, delegated access is instead OAuth 2.0 in combination with OpenID Connect: an authorization server issues short-lived access tokens with a narrowly scoped set of permissions, rather than storing permanently valid passwords in the code.
For machine-to-machine communication between shop and ERP, mutual TLS is added. With mTLS, both sides identify themselves with certificates -- not only the server to the client, but also the client to the server. With RFC 8705, the IETF standardizes OAuth 2.0 authentication over mTLS and certificate-bound access tokens, so a token is only usable with the matching client certificate (IETF RFC 8705). A stolen token alone no longer gets an attacker anywhere. Our comparison of REST API versus middleware shows how to bundle this logic in one central place.
| Aspect | Old connection | NIS2-compliant connection |
|---|---|---|
| Authentication | Static API key or Basic-Auth | OAuth 2.0 with OpenID Connect |
| Machine-to-machine | Password in the code | mTLS with client certificates (RFC 8705) |
| Token validity | permanent, rarely rotated | short-lived, automatically renewed |
| Permission scope | full access | narrowly scoped per task |
| Revocation | only via global key swap | targeted per token or certificate |
OAuth 2.0 and OIDC
Delegated authorization with short-lived tokens and verifiable identity -- no more password in the integration source code.
mTLS between services
Mutual certificate verification for service-to-service communication, bound to the respective client certificate.
Least privilege
Each access receives only the rights it needs for its task -- narrowly scoped permissions instead of blanket full access.
Multi-factor for operators
Access to the administration and deployment of the interface is protected with multi-factor authentication, as Section 30 of the BSI Act requires.
Automatic rotation
Keys and certificates are renewed regularly and without downtime, so compromised secrets quickly become worthless.
Object authorization
Every request checks authorization per record and thus rules out the broken object level authorization at OWASP's number one.
Step 4: Monitoring and Reporting Duty
NIS2 requires not only prevention but also the ability to detect incidents and report them on time. For a significant security incident, a tiered reporting chain to the BSI applies: an initial notification within 24 hours, a detailed report after 72 hours and a final report after one month at the latest (BSI). These deadlines can only be met if the interface logs completely and anomalies stand out automatically.
- Access logs: every call with timestamp, identity, endpoint and result -- the basis for any later reconstruction.
- Anomaly detection: conspicuous patterns such as sudden bulk queries of individual records or unusual access times are detected and alerted.
- Rate limiting: limited call rates protect against automated extraction and against the unrestricted resource consumption OWASP lists as API4:2023.
- Error and outage monitoring: rising error rates or timeouts point early to attacks or disruptions.
- Retention: logs are kept in an audit-proof way long enough that an incident can also be investigated retrospectively.
Speed before completeness
Our article on the observability of interfaces describes how end-to-end monitoring of interfaces is set up technically. Closely linked is clean error handling in interfaces, because only those who make error states visible can tell an attack from a harmless disruption. To put the threat landscape in context: DDoS attacks were recently the most commonly reported cyber threat in the EU, at over 46 percent (ENISA).
Step 5: Supply-Chain Evidence
Section 30 of the BSI Act explicitly names supply-chain security as a measure in its own right, including the security-related aspects of relationships with direct suppliers and service providers (BSI). For ERP-to-shop interfaces this is especially relevant because third parties are almost always involved: the shop operator, an ERP service provider, a payment connection or an external middleware provider. Each of these parties can itself become an entry point.
OWASP lists the insecure use of third-party interfaces as API10:2023 Unsafe Consumption of APIs -- the unchecked trust in the data and availability of third parties (OWASP). How real this danger is was shown by the backdoor in XZ Utils documented by ENISA: a compromised open-source package could endanger entire software supply chains (ENISA). For the operator of an interface, this means not assuming the security of the embedded services but having it demonstrated.
Contractual assurances
The security requirements and reporting duties of service providers are anchored contractually, so an incident at the provider does not go unreported.
Software bill of materials
An overview of the embedded components and libraries makes visible which third-party software is in the interface and must be kept current.
Certificates and audit reports
Evidence such as independent audit reports or certifications of the providers documents their security level in a traceable way.
Regular reassessment
The risk assessment of the providers is carried out not once but repeatedly and updated when things change.
Credit and third-party services belong in the supply-chain picture
The Path to a NIS2-Compliant Interface
The path from a grown connection to a NIS2-compliant interface can be taken in a structured way. It rarely starts with a rebuild, but with an honest look at what exists: which interfaces are there, how are they secured and where are the gaps against Section 30 of the BSI Act. Priorities follow from this finding -- the biggest risks first, the rest in a plannable order afterwards.
1. Audit and inventory
Complete capture of all interfaces, assessment of authentication, encryption and logging against the NIS2 requirements.
2. Hardening
Replacing static keys with OAuth 2.0, OpenID Connect and mTLS, end-to-end encryption and the introduction of monitoring and rate limiting.
3. Documentation
Traceable documentation of interfaces, measures and supply-chain evidence as the basis for audits and reports.
4. Compliant development
New interfaces are developed to NIS2 standards from the start -- with secure defaults, least privilege and built-in monitoring.
NIS2 is not a one-off project but an operating state. An interface that is documented, encrypted, cleanly authenticated and monitored not only meets the duty but also runs more reliably.
Anyone embedding hardening into a larger integration strategy will find further approaches in our article on the OCI PunchOut connection of procurement portals as well as on the SAP Integration Suite and clean-core connection. Both show how security can be thought of not as an afterthought but as part of the architecture.
Sources and studies