They create risk because many of them sit outside the cleanest identity architecture and do not support native MFA in the same way as modern applications. That forces firms into exception handling or wrapper controls, and those are exactly the places where audit evidence and enforcement often break down.
Why legacy and SaaS applications create the hardest MFA gap
Legacy and SaaS applications are risky because they often do not sit inside the same modern identity stack as newer apps. When native MFA is missing or inconsistent, teams end up relying on exception paths, proxy controls, conditional access workarounds, or password-only fallback flows. That is where enforcement, logging, and audit evidence tend to become uneven.
Modern MFA programs work best when the app can participate directly in centralized authentication, step-up decisions, and account lifecycle controls. A legacy app may still depend on local credentials, embedded auth logic, or protocols that were never built for today’s phishing-resistant methods. A SaaS app may support MFA in theory, but only through a vendor-specific setting, partial federation, or separate admin portal that creates a second control plane.
That gap matters because NYDFS compliance is not just about whether MFA exists somewhere in the environment, it is about whether access to covered systems is consistently protected and defensible. If the application cannot enforce the same sign-in rules as the rest of the estate, the control becomes patchy by design. MFA Guide is useful here because it distinguishes strong authentication from weaker fallback patterns that often survive in older environments. Workforce Identity Security Guide also helps because it shows how SSO, federation, and account recovery reduce the chance that one outlier app becomes a compliance exception.
Where exception handling turns into audit failure
Exception handling is the real compliance trap. Once an application cannot support native MFA, the organisation has to prove that the compensating control is effective, consistently enforced, and reviewed over time. In practice, that is harder than it sounds because the evidence often lives in multiple places, such as the IdP, the app admin console, ticketing records, and manual attestations.
Legacy and SaaS applications also create hidden drift. Security teams may believe MFA is active because the main login path is protected, while privileged access, break-glass accounts, API access, or alternate user flows still bypass the control. The result is a control that looks complete in policy but breaks at the edges. IAM and Identity Provider Buyer’s Guide is relevant because application onboarding, federation support, and admin security determine whether an app can be brought into the standard control plane or left as an exception.
For SaaS, the other failure mode is vendor fragmentation. A platform may support MFA for end users, but not for all privileged roles, not for every API or service account, or not in the exact tenant configuration the firm needs. That is why compliance reviews should focus on the actual access path, not the vendor brochure.
Why the risk gets worse with scale and poor app inventory
The risk compounds when the application estate is large, heterogeneous, or poorly inventoried. Every extra exception creates another place where the firm must prove who can access what, through which method, under which conditions, and with what evidence. Over time, that creates a long tail of controls that are technically acceptable but operationally fragile. MFA Guide is also relevant because it covers legacy authentication and MFA exclusions, which are the exact mechanisms that tend to survive in mixed estates.
That is why applications with weak MFA support often become the biggest NYDFS risk even if they are not the most valuable systems. They are difficult to standardise, difficult to monitor, and easy for business owners to treat as special cases. The more the estate depends on those exceptions, the more the organisation relies on manual assurance instead of durable control design. NIST SP 800-63 Digital Identity Guidelines is a useful reference point because it clarifies the value of phishing-resistant authentication and strong assurance rather than merely adding another factor.
Risk and Threat Considerations
Legacy and SaaS apps become compliance weak points because attackers do not need to defeat the strongest control if they can find the weakest access path. A single exempted app, dormant account, or fallback login flow can bypass the MFA standard and give an attacker a foothold that still looks legitimate in logs.
Failure mechanism: Native MFA is missing, partially implemented, or bypassed by alternate login methods, so the control depends on exceptions, compensating controls, or inconsistent vendor settings.
Impact: The organisation loses assurance that access is uniformly protected, and audit evidence becomes harder to defend because the real enforcement model is fragmented across systems.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Phishing-resistant authentication and assurance levels directly shape MFA strength for covered applications. |
| Recommendation — Use assurance levels to standardize MFA strength and reduce fallback exceptions. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Employee app access hinges on enforcing MFA for organizational users. |
| IA-5 — Authenticator Management | Legacy and SaaS exceptions often fail through weak credential lifecycle control. | |
| IA-8 — Identification and Authentication (Non-Organizational Users) | SaaS access often includes external users whose MFA coverage must also be enforced. | |
| Recommendation — Require strong user authentication on application sign-in paths. Manage authenticator issuance, rotation, and revocation across all app paths. Apply strong authentication to external and partner-accessed applications. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The question is about consistent access enforcement across mixed application estates. |
| Recommendation — Define and enforce access requirements for each application access path. | ||
Practitioner Guidance
What to verify: For every legacy or SaaS application, confirm the exact sign-in path, not just whether the product “supports MFA.” Check whether privileged users, service accounts, recovery flows, and API access are all covered by the same enforcement model.
Decision rule: If the app cannot participate in the standard identity control plane, treat it as a formal exception with explicit ownership, expiry, and compensating control review. Do not leave it as an informal business waiver.
What good looks like: The best state is not universal native MFA in every product, but a small and well-governed exception set where each outlier has documented enforcement, monitoring, and a plan to retire the exception over time.
Practitioner takeaway: The biggest NYDFS risk is not simply “old software,” it is any app that forces MFA into exception mode, because exceptions are where control design, evidence, and accountability tend to fail first.
Related resources from NHI Mgmt Group
- Why do non-human identities create compliance risk even when policies exist?
- Why do SaaS integrations create compliance risk under NYDFS?
- Why do legacy authentication methods create compliance and security risk under NYDFS Part 500?
- Why do legacy OAuth applications and abandoned SaaS identities create such a high breach risk?