NIS2 puts MFA on the agenda for privileged access. In a modern IT environment, that may mean enabling a control the system already supports. On a plant floor, the account may lead to a controller, engineering workstation or vendor system that was installed 20 years ago and cannot take a second factor.
Those systems may run production, depend on shared credentials or operate inside validated environments where changing authentication can mean downtime and recertification. Replacing them to satisfy one security control may not be realistic either.
NIS2 leaves room for risk through the phrase “where appropriate,” but legacy technology does not automatically fall outside the requirement. Article 21 includes MFA among the baseline security measures, while Commission Implementing Regulation (EU) 2024/2690 points specifically to remote access, privileged accounts and system administration accounts. ENISA’s implementation guidance also expects the strength of authentication to reflect the sensitivity of the access being protected.
For security teams responsible for older operational systems, the question is how to put MFA around access that cannot support it natively. In many cases, MFA can be applied before the legacy system receives the credential, using a privileged access gateway or credential store to broker access.
Key insights
- NIS2 Article 21 lists MFA among its baseline measures, and legacy operational systems are not exempt because they cannot run it natively.
- Commission Implementing Regulation (EU) 2024/2690 names remote access, privileged accounts and system administration accounts as where MFA applies first.
- Switching on mandatory MFA without an account inventory breaks integrations, because technical and service accounts cannot take a second factor.
- A policy exception signed off by the board explains why a legacy system lacks MFA but leaves its privileged access protected by a password alone.
- Contributors to a 2026 NIS2 access management report describe a layered fix: authenticate the person at an MFA-protected credential store or gateway, then let it broker the password the legacy system already accepts.
- The MFA method should match the access it protects; SMS codes and phishing-resistant hardware keys do not carry the same weight in an audit.
Why MFA for legacy systems breaks on the plant floor
An authentication prompt that locks an operator out of an HMI during an upset condition can stop production or create a safety problem. NIST guidance for operational technology recognizes the importance of availability and safety in these environments. A change to authentication on a control workstation may also trigger validation work or downtime that would be routine on a corporate endpoint.
Then there is the amount of old equipment still in service. Engineering workstations, historians, batch controllers, mainframes and vendor-supplied panels can remain operational for decades. Some cannot accept another authentication factor. Others come from manufacturers that no longer support them.
The account inventory can be just as difficult. Passwork’s 2026 NIS2 access management report brings together five experts from government, industry and cybersecurity to examine how organizations are putting the directive into practice. One of its contributors, Dr. Yiannis Pavlosoglou, Deputy Governor at the Greek National Cybersecurity Authority, describes what happens after an organization switches on mandatory MFA. Leadership exceptions appear first. Then IT discovers technical accounts and other credentials embedded in applications and integrations, many of which cannot simply be given a second factor.
“Turning the control on is easy,” says Pavlosoglou. “Making it work across the organisation is the real challenge. If we don’t do it right, In less than 24 hours we will cheese off everyone in the organization and break pretty much all system integrations in the name of one cybersecurity control.”
Operational environments have their own versions of this problem. An engineer’s credential may have found its way into a service or scheduled task years ago. Several technicians may use the same login at a console, while older remote access into industrial environments can leave vendor and contractor accounts outside newer authentication controls.
Finding those dependencies before enforcing MFA can prevent the rollout from creating a new collection of exceptions or taking an integration offline.
Legacy systems cannot become permanent MFA exceptions
Pavlosoglou uses an AS/400 in a bank to illustrate the problem. An old mainframe may still perform a critical function while having no practical way to support MFA itself. The same is true of plenty of equipment in manufacturing and other operational environments.
Pavlosoglou connects that technical limitation with the way organizations write their NIS2 policies:
“Somebody can take the requirements that NIS2 mandates, and then draft corporate policies that leave gray areas. Implement the security control, and then take that to the board, get sign-off, and that’s it. You haven’t actually achieved anything.”
A signed exception may explain why MFA cannot run on a particular system, but the privileged access still needs protection.
Pavlosoglou also points to the amount of technology across Europe that cannot support current access controls. Leaving each of those systems outside MFA preserves the identity and access practices that have grown around them, including shared credentials, old technical accounts and administrative access protected by a password alone.
He argues that CISOs need to take more than the exception to management. If legacy applications or groups of users still lack a second factor, the board needs the risk expressed in business terms and a plan for improving the position.
Put MFA in front of the legacy system
A privileged access gateway or MFA-protected credential store can authenticate the operator before releasing the credential used by the legacy system. Still, the controller, workstation or mainframe continues to receive the username and password it already accepts.
Alex Muntyan, Passwork CEO and another contributor to the report, describes the sequence as a layered approach.
“You put the MFA on the front door, in the password manager itself, and then you let the password manager broker access to all these tools.”
His approach reflects a problem that recurs across the report, from manufacturing environments to banking infrastructure. An AS/400 in a bank can present the same obstacle as a controller on a shop floor and both of them may need to keep their existing authentication mechanism while the organization controls access before the credential reaches them.
Brokered access can help with shared accounts too. The legacy application may continue to record one generic login, while the access system records which employee requested the credential, when it was released and the session associated with it.
The takeaway here is that network segmentation belongs alongside this architecture. It can restrict which systems an authenticated account can reach, while the gateway controls and records access to the credential. And neither requires changes to the authentication mechanism on the legacy device.
The MFA method still matters
Putting MFA in front of the system gives security teams more choice over how different workers authenticate. The controller does not need to understand a FIDO2 key, passkey or tap card—only the access layer does.
That flexibility matters in operational environments where one authentication method may not work for everyone. Engineers may be able to carry security keys. Line staff wearing gloves or working in clean rooms may need cards they can tap. Contractors can receive passkeys limited to a maintenance window. Phone-based codes may still be needed where other methods are impractical.
The strength of those methods differs too. SMS and email one-time passwords remain vulnerable to interception and other attacks. Phishing-resistant methods such as FIDO2 and WebAuthn hardware keys provide stronger protection.
Attackers have also learned how to phish MFA by persuading a legitimate user to complete the second factor. A control register that says only “MFA enabled” misses those differences, so the authentication method should reflect the sensitivity of the access it protects and the conditions under which operators, engineers and contractors need to use it.
Find the accounts still relying on a password
A plant can start with the accounts that reach its critical systems, which includes named administrators, shared credentials, contractors and technical accounts that may have become dependencies for other systems over time.
Some systems will already support MFA, others can take it without affecting operations, but older equipment may need access to pass through a gateway or credential broker first.
The accounts that need attention are the privileged and remote access routes still relying on a password, with no stronger authentication before the credential reaches the system. Those are the accounts to bring into the next access review.
Bios
Dr. Yiannis Pavlosoglou is the Operational Deputy Director of the Greek National Cybersecurity Authority; he is a senior cybersecurity executive with 20 years of experience in risk assessment and management, as well as information assurance. He has served as the UK Chief Information Security Officer at UBS. He was a member of the Board of Directors of ISC2, serving as its Chair in 2023. He holds a PhD in Engineering for Secure Protocol Design and a Bachelor of Engineering in Computer Systems Engineering from the University of Warwick in the UK.
Alex Muntyan is the CEO of Passwork, a European cybersecurity company offering password and credential management. Before moving to Passwork, we served for over 15 years in B2B sales and marketing roles, scaling revenue operations for leading SaaS companies across Europe and North America.
Author Bio
Madalina Pandrea is a cybersecurity and technology writer and editor, specialising in human-centric, product-led content. She’s interested in the stories that go beyond features to explore how technology changes the way people work, think, and live. Madalina works with brands and industry experts to translate complex products, technical concepts, and emerging trends into clear, compelling stories that people understand and trust.
