How should manufacturers reduce identity risk when legacy applications cannot support MFA?

Manufacturers should place a control layer in front of legacy applications so access can be evaluated before credentials reach the target system. The practical goal is to verify risk on every sign-in attempt, not to rely on the application’s native authentication. That approach helps preserve operational continuity while reducing the chance that compromised credentials can unlock older systems or production resources.

Why a control layer is the right answer when MFA is missing

When a legacy application cannot enforce MFA, the security decision has to move to the access path in front of it. That control layer becomes the point where the organization can check device state, user risk, session context, network conditions, and sign-in signals before the application ever sees the request. The important shift is to treat the legacy system as an unmodified target, not as the place where modern identity policy will be retrofitted.

This matters because older applications often cannot distinguish between a legitimate legacy login and a replayed or stolen credential. A front-end control can still preserve operational access while reducing exposure to credential theft, password spraying, or reuse of accounts that were never designed for modern authentication controls. In practice, the best designs let the legacy app remain stable while the surrounding access plane does the security work.

That pattern is visible in real-world compromise paths such as the Microsoft Midnight Blizzard breach, where a legacy account without MFA became an access path. The lesson is not that every old system must be rebuilt immediately, but that weak sign-in paths need compensating controls that sit before the application.

What the control layer should evaluate before access is allowed

The control layer should make an allow or deny decision based on more than a password alone. At minimum, it should be able to evaluate whether the login attempt is coming from an expected device, a known location or network, a trusted session, and a user or account that still makes sense for the requested resource. For manufacturers, that often means protecting remote access to production systems, plant support tools, and high-value engineering applications with stronger policy than the application itself can provide.

Where possible, the control should also reduce direct exposure of legacy credentials. If an attacker steals a password, they should still have to clear the surrounding policy layer before reaching the target. That is the practical difference between allowing the app to authenticate users directly and forcing every request through a checkpoint that can apply modern policy. If the legacy application is part of a broader identity stack, this is also where OWASP Non-Human Identity Top 10 concerns can matter, especially when service accounts or other machine credentials are used to bridge older systems.

For a broader treatment of how access governance, secrets, and lifecycle controls fit together, NHIMG’s Ultimate Guide to NHIs is the most useful reference point, and the more focused Top 10 NHI Issues is a practical companion when legacy access depends on long-lived accounts, secrets, or shared credentials.

How to reduce risk without breaking production operations

Manufacturing environments usually cannot tolerate a security redesign that interrupts plant-floor access, vendor support, or scheduled production changes. That is why the control layer should be introduced as a compensating design, not as a hard cutover that depends on the legacy application being changed first. The goal is to preserve continuity while shrinking the blast radius of any single compromised credential.

A sensible implementation sequence is to start with the highest-value legacy applications, wrap them with policy enforcement, and then tighten the conditions for access in stages. Over time, organizations can move from simple gating to stronger conditional access, stronger logging, and better account review. If the legacy application supports no modernization at all, the surrounding access layer becomes the primary place to enforce risk-based access and to decide when an exception is acceptable.

For machine and workload access that still has to touch older systems, the same principle applies to service identities. NHIMG’s definition of non-human identities helps frame where service accounts, tokens, and certificates should be governed as access-bearing credentials rather than treated as afterthoughts. In adjacent infrastructure environments, the SPIFFE workload identity specification shows the direction of travel for stronger machine authentication when older point-to-point trust has to be replaced.

Risk and Threat Considerations

Legacy applications without MFA are attractive because they often sit in the middle of valuable operational workflows but still rely on weak or reusable credentials. If those credentials are phished, guessed, reused, or stolen from a nearby system, an attacker can authenticate as a legitimate user and move directly into production-adjacent resources.

Failure mechanism: The failure is not only the absence of MFA, but the absence of a compensating enforcement point that can evaluate context before the legacy application receives the login. When that checkpoint does not exist, the application accepts the credential as if it were trustworthy by default.

Impact: The result can be unauthorized access to production systems, vendor tools, or sensitive operational data, with a much larger blast radius than the original login event suggests. In manufacturing, that can affect uptime, process integrity, and recovery effort, especially if privileged or shared accounts are involved.

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 NIST CSF 2.0, NIST SP 800-63, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	PR.AC-1 — Identity Management, Authentication and Access Control	Covers strong access decisions before legacy app entry.
	PR.AC-3 — Remote Access is Managed	Legacy manufacturer access often depends on managed remote entry paths.
	PR.AC-4 — Access Permissions and Authorizations Are Managed	A front-end control layer must authorize each sign-in attempt by risk and context.
Recommendation — Enforce pre-access identity and access controls for legacy application entry points. Restrict and monitor remote access to legacy production systems. Apply risk-based authorization before allowing access to legacy systems.
NIST SP 800-63	IAL/AAL/FAL — Identity Assurance, Authenticator Assurance, Federation Assurance	Supports stronger authentication assurance when the app cannot do MFA itself.
Recommendation — Use stronger authenticator and federation assurance at the access layer.
NIST Zero Trust (SP 800-207)	SC-2 — Device Authentication and Authorization	Zero Trust access should evaluate device and session trust before granting entry.
Recommendation — Authenticate and authorize devices and sessions before legacy access is granted.
CIS Controls v8	6 — Access Control Management	Prescriptive control for limiting and reviewing access paths to legacy systems.
Recommendation — Centralize access control around legacy applications and remove direct paths.
OWASP Non-Human Identity Top 10	NHI-01 — Secrets and Credential Management	Legacy access often depends on long-lived credentials that need front-end protection.
	NHI-03 — Privilege and Access Governance	Compensating controls must reduce excessive access on legacy paths.
	NHI-06 — Detection and Response	Front-end enforcement should also produce logs and signals for compromise detection.
Recommendation — Protect legacy credentials with stronger governance and exposure reduction. Minimize legacy account privilege and gate access by policy. Log and alert on unusual legacy sign-in attempts and access patterns.

Practitioner Guidance

What to verify: Confirm that the control layer actually blocks access before the legacy application receives a session, and do not trust a design that only logs the event after the fact. If the legacy system can still be reached directly, the compensating control is incomplete.

Decision rule: If a legacy account can reach production or engineering resources, treat it as a high-risk access path until you can prove that the surrounding policy layer enforces context, visibility, and exception handling. If it cannot be wrapped safely, isolate it further and reduce what that account can touch.

Practitioner takeaway: The objective is not to make the old application modern, it is to make the access path modern enough that a stolen credential is no longer sufficient on its own.