NYDFS regulations require effective multi-factor authentication (MFA) for covered financial entities but do not single out or directly prohibit or endorse specific protocols such as OATH TOTP or HOTP. The focus is on real-world risk management, proper coverage, and the proven effectiveness of the MFA method implemented, rather than on specific technologies or algorithms.[1]
NYDFS Wording and MFA Expectations
The regulation mandates MFA for all remote access to internal networks and for privileged accounts unless the CISO has formally approved "reasonably equivalent or more secure access controls." MFA is also required for third parties (such as agents or contractors) who can access internal systems or nonpublic information.[1]
NYDFS clarifies not all MFA is equal: The guidance explicitly distinguishes token-based MFA (such as authenticator apps and hardware tokens producing one-time passcodes) as more secure than push-based or SMS MFA, which are prone to user error or interception. TOTP and HOTP are considered token-based MFA and thus fall into the favored category when used and managed well.[1]
However, DFS stresses the implementation must be effective: "Covered Entities should test and validate the effectiveness of MFA implementation... authentication control strength and identification of weaknesses or gaps in MFA as implemented and configured."
OATH TOTP/HOTP and NYDFS Objectives
TOTP (Time-based) and HOTP (Counter-based) both match NYDFS expectations for token-based MFA if deployed using proper lifecycle controls and user management. Both generate one-time passcodes using a shared secret, requiring users to possess an authenticator device or app. However, if users share this secret, OATH protocols alone do not ensure that access is truly “something only the individual possesses,” reducing the effectiveness against account sharing or insider threat.[1]
Mitigating Controls for OATH MFA Use
Given DFS's emphasis on “effectiveness” and “risk-based” controls, organizations using OATH protocols should consider adding the following mitigating measures:
**Controlled Seed and Device Enrollment:** Only allow MFA device registration via company-controlled processes; avoid self-service registration or allow it only with secondary verification (e.g., supervisor approval, video verification, etc.).
**Seed Non-Exportability:** Use authenticators/devices where extraction of the shared secret is not possible post-provisioning (e.g., some hardware tokens or managed MDM-locked apps).
**Device Re-Enrollment & Attestation:** Regularly require re-enrollment of MFA devices, possibly including device attestation or physical presence if feasible.
**Monitor/Alert for Suspicious Patterns:** Flag and investigate OTPs used from multiple locations/devices, highly synchronized OTP entries, or frequent changes in device registration.
**Policy Enforcement and User Education:** Clearly communicate the risks and consequences of factor/account sharing and enforce with disciplinary or contractual actions.
**Compensating Controls:** If effective MFA enforcement is not feasible, use additional controls such as behavioral analytics, device fingerprinting, IP allow lists, or step-up authentication on high-value transactions to compensate.
Commentary
Deploying OATH TOTP/HOTP can satisfy NYDFS requirements if controls ensure that OTP credentials are both unique to each user and non-transferable in practice. The key is to align deployment and controls with risk-based, observed effectiveness, and to document this justification in both risk assessments and security policy, especially for external agents where direct device control is limited. Where OATH is used and these issues are significant, NYDFS may expect documented risk-based decisions and compensating controls to be in place.[1]
In summary, OATH-based MFA is generally aligned with NYDFS’s requirements for token-based MFA; the challenge is to maintain effective uniqueness and resistance to sharing through layered procedural and technical safeguards.NYDFS regulations require the use of “effective” multi-factor authentication (MFA) for both employees and third-party agents but do not specifically mention or prohibit OATH protocols like TOTP or HOTP. Their guidance emphasizes risk-based assessment, actual effectiveness of the chosen MFA method, and the need for controls that “protect against unauthorized access” to sensitive data and systems. The guidance is worded generally, placing the onus on covered entities to ensure that MFA reduces risk in practice, including when used for agents or non-employees.[1]
Exact NYDFS Wording
“Covered Entities…must use MFA for remote access to all internal networks, including applications and systems… unless their CISOs have approved ‘the use of reasonably equivalent or more secure access controls.’”
“Token-based MFA requires a user to manually enter a one-time use passcode generated by a hardware or software device…”
“DFS has seen several Cybersecurity Events where inattentive users allowed a cybercriminal to gain access…by authenticating push-based MFA. With token-based authentication, a user is less likely to unwittingly grant access…”
“Covered Entities should also test and validate the effectiveness of MFA implementation… IT audits, penetration tests, and vulnerability scans should include verification of MFA control strength and identification of weaknesses or gaps in MFA as implemented and configured.”
Alignment of OATH TOTP/HOTP with NYDFS Guidance
TOTP and HOTP are “token-based” methods and are specifically referenced as being generally more secure and effective than methods relying on push notifications or SMS.[1]
However, NYDFS’s focus on “effectiveness” means that implementation must be designed to minimize risks such as account/factor sharing, improper device registration, and weak exception management.
The risk that users could share their OATH seed directly undermines the effectiveness of MFA in the context of NYDFS goals, so the regulatory expectation is that organizations recognize this risk and mitigate it with additional controls or alternative MFA methods where practical.[1]
Recommended Mitigating Controls
**Controlled Enrollment**: Require initial device registration to be performed in person, by a trusted party, or with secondary identity verification.
**Hardware Tokens or Managed Apps**: Where possible, deploy OATH credentials to hardware tokens or administratively managed mobile devices, rather than allowing unrestricted user registration.
**Strict Re-Enrollment and Auditing**: Enforce periodic re-verification of registered MFA devices and audit for patterns consistent with account or token sharing.
**Compensating Analytics**: Layer additional controls like behavioral analytics, device fingerprinting, or session monitoring to detect suspicious authentication patterns.
**Educate and Enforce Policy**: Train agents (and non-employees) on policy around factor sharing and enforce with monitoring and disciplinary/contractual consequences.
**Documented Risk Assessment**: Clearly articulate in risk documentation the controls and limitations of OATH, and why the chosen scheme is “reasonably equivalent or more secure” for the use case.
In summary, OATH TOTP and HOTP can align with NYDFS regulations when deployed in a way that maintains their “effectiveness” in preventing unauthorized access, but careful operational and technical controls and supporting documentation are necessary, especially where agent/account sharing is a risk.[1]
[1] https://www.dfs.ny.gov/industry_guidance/industry_letters/il20211207_mfa_guidance