Security Standards for External Developers: Access, Secrets, Audits

External developers are often deeply embedded in their clients’ systems, with access to source code, databases, and sometimes production environments. As of December 6, 2025, the NIS2 Implementation Act makes this access a separate obligation under the BSI Act. Anyone who ignores these requirements risks hefty fines and, in the worst-case scenario, a security breach that no one can trace to a specific source.

Section 30 of the BSIG lists ten minimum measures for critical and important facilities; several of these directly affect suppliers and external service providers. For IT management and procurement, this means more substantive provisions in contracts with software service providers, similar to the requirements set forth in the GDPR and NIS 2 Compliance in Nearshoring.

The legal basis in § 30 BSIG

The NIS2 Implementation Act has been in effect in Germany since December 6, 2025, and is implemented primarily in the revised § 30 BSIG. Paragraph 2 lists ten minimum measures for critical and important facilities. Item 4 concerns supply chain security, including relationships with direct suppliers and service providers; item 9 concerns access control; and item 10 concerns multi-factor authentication.

Particularly important organizations have at least 250 employees or annual revenue of more than 50 million euros and total assets of over 43 million euros. Important organizations have 50 employees or revenue and total assets of 10 million euros. Violations of risk management obligations may result in Fines of up to 10 million euros, and for corporations with revenue exceeding 500 million euros, up to 2 percent of global annual revenue.

Individual Accounts Instead of Collective Accounts

Under NIS2, a shared password for the entire partner team is no longer a viable solution. Each employee of an external development partner is assigned their own, personally identifiable account linked to the specific project. Without this assignment, it is impossible to determine who made which changes in the event of a security incident, and this is precisely what the 24-hour reporting requirement for security incidents under Section 32 of the BSIG mandates.

In practice, this means one named account per person at the partner company, not per project or client. If a developer leaves the service provider, her access is revoked, regardless of whether the project is still ongoing. A registry of all assigned access rights makes this assignment traceable during an audit.

MFA and Privileged Access for External Developers

For privileged accounts and remote access, the technical guideline from the European Cybersecurity Agency (ENISA) Exclusively phishing-resistant multi-factor authentication, such as FIDO2 or WebAuthn with a hardware key or passkey. SMS codes and simple push notifications are no longer sufficient for administrator access. Developers at partner companies who access production systems fall into this category, regardless of whether they are internal or external employees.

Separate administrator accounts are part of the same package. Anyone who both writes production code and needs server access works with two identities, one for development and one for administrative tasks. This prevents a compromised developer account from automatically gaining privileged access to the infrastructure.

Just-in-Time Access and Automatic Revocation

Permanent admin access for partner companies poses a distinct risk in the context of NIS2. Just-in-time access reverses this principle: privileges are granted for a defined session, logged, and then automatically revoked. For a two-hour maintenance task, this means two hours of privileged access, not two years.

Access revocation must also be linked to the contract. If the service contract ends or a project expires, access is automatically revoked, not only after a manual notification from the purchasing department. In many companies, a privileged access management system that technically enforces this linkage is replacing the previously informal email-based agreements.

Audit Logging and Contractual Obligations

Every action taken by external developers on production systems must be recorded in a tamper-proof log that captures the user's identity, timestamp, action, and source IP address. This forms the basis for forensic investigation following an incident; without it, it is nearly impossible to pinpoint the scope of a security incident.

Contracts with external development partners should specify at least three points: security requirements for the software delivered, the right to conduct audits with regular reporting obligations, and a reporting deadline of no more than 24 hours for security-related incidents. These clauses supplement the Intellectual Property Protection in Nearshoring, which many contracts already cover.

Frequently Asked Questions

Does § 30 BSIG also apply to smaller contracting entities?

Only particularly important entities with 250 or more employees or 50 million euros in revenue, and important entities with 50 or more employees or 10 million euros in revenue in a regulated sector, are directly subject to the requirements. Smaller suppliers and software partners are nevertheless subject to these requirements as soon as a customer subject to NIS2 imposes contractual security requirements on them. Those who already use personal accounts and MFA today will have shorter contract negotiations tomorrow.

Is a standard MFA app sufficient for developer accounts?

For standard accounts, ENISA’s technical guideline accepts a TOTP authenticator app. For privileged and administrative access, it requires phishing-resistant methods such as FIDO2 or WebAuthn; SMS codes are considered obsolete. Those who do not distinguish between standard and administrative access either set unnecessarily high barriers for simple tasks or set barriers that are too weak for critical systems.

How quickly must access be revoked after the contract ends?

The law does not specify a fixed number of hours for the revocation itself, but it does set a 24-hour deadline for reporting security incidents under Section 32 of the BSIG. In practice, auditors expect an immediate, automated revocation as soon as a contract ends or a project is completed. A manual process that relies on an email from the procurement department is considered a vulnerability during an audit.

torck implements the measures described here in its own setup before a customer even asks for them. External developers at torck use personal accounts, FIDO2 MFA, and logged access, regardless of whether they are based in Maxhütte-Haidhof, Vienna, or Rabat. Because the time difference between Germany, Austria, and Morocco is no more than two hours year-round, a security incident can be resolved in real time, rather than having to wait until the next morning. The contractual partner remains the German company torck GmbH throughout the entire process, a single contract rather than a chain of subcontractors, with German-speaking project management serving as the direct point of contact for reporting obligations under Section 32 of the BSIG. More information about the setup is available on the page for Nearshore Software Development.

Schedule a meeting