OTP at Windows 10 login

NIST 800-171r2 and 800-171r3 require a removable multifactor to be compliant.

TPM + PIN does not satisfy that requirement, unless you are referring to a security key as TPM. Further, the device needs to be FIPS 140-2 compliant to satisfy MFA cryptography compliance requirement in 800-171r2.

800-171r3 will require FIPS 140-3, but we still have until Q3 2025 for organizations handling CUI to meet 800-171r2 and no specified deadline for 800-171r3 compliance.

There are FIPS compliant phones, that can generate time based tokens for login, when combined with an unlock pin, but remember all mobile devices must be managed by the organization and cannot have camera access where CUI is handled per 800-171r2.

For 800-171r3, they’ve expanded that to include microphone access.

As an aside, I have yet to see a single correct resource regarding NIST compliance (including the NIST Compliance sub reddit).

I manage multiple compliant organizations, and specifically remediate for compliance. Shit is mind numbingly bureaucratic but genuinely sounds advice as all controls are derived from attacks seen in the wild.

1 Like

“It’s there for a reason”

2 Likes

Thanks for additional info. I had found this MS article which cites the same NIST doc as well as others to support their argument that PIN is indeed MFA, but frankly it’s over my head. Seemed like they were doubling down on their stance that it meets the letter of the requirements.

2 Likes

looks like the doc they cite assuring hardware inbuilt TPM is acceptable as a factor is from 2017 though so perhaps it has been obsoleted? I have not yet begun to dig into actual letter of CMMC ratified specs.

1 Like

this is from Microsoft and technically correct IF you are not accessing any network resources:

"Only privileged users are required MFA for local access (if regular user accounts have administrative rights only on their computers, they are not considered a “privileged account” and as such do not require MFA authentication for local access). "

Per NIST 800-171r2:
"3.5.3: Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts

Multifactor authentication requires the use of two or more different factors to authenticate. The factors are defined as something you know (e.g., password, personal identification number [PIN]); something you have (e.g., cryptographic identification device, token); or something you are (e.g., biometric). Multifactor authentication solutions that feature physical authenticators include hardware authenticators providing time-based or challenge-response authenticators and smart cards. In addition to authenticating users at the system level (i.e., at logon), organizations may also employ authentication mechanisms at the application level, when necessary, to provide increased information security.
Access to organizational systems is defined as local access or network access. Local access is any access to organizational systems by users (or processes acting on behalf of users) where such access is obtained by direct connections without the use of networks. Network access is access to systems by users (or processes acting on behalf of users) where such access is obtained through network connections (i.e., nonlocal accesses). Remote access is a type of network access that involves communication through external networks. The use of encrypted virtual private networks for connections between organization-controlled and non-organization controlled endpoints may be treated as internal networks with regard to protecting the confidentiality of information.
"

So, in theory a local non privileged account lacking network access is exempt from the requirement. But that means all data has to be hosted local and not shared in any way. The idea was the industrial machines and appliances that cannot have multi factor enabled, are exempt from the requirement. Problem is machines cannot be on the network without multi factor, and removable media is controlled so the only way to load programs to machines is through a dedicated connection that is not traversable.

You end up with a workstation at each machine for loading programs. Each workstation requires multi factor to access the network shared data, then loaded to the machine directly.

This is fundamentally incorrect

again
Per NIST 800-171r2:
" 3.1.5: Privileged accounts, including super user accounts, are typically described as system administrator for various types of commercial off-the-shelf operating systems. "

No idea where this guy gets the idea that local admin accounts are not considered “privileged accounts” when he could have simply read more of the NIST documentation…

I thought there was something behind that article like a missing context on why “Local admins” would not be considered “privileged accounts”, but nope, that’s one glaring jump in conclusions.

1 Like

The bit about not needing MFA for unprivileged local accounts seems out of place in an article about achieving MFA. The bottom section is about why/how Hello with PIN + TPM is acceptable MFA.

If Hello PIN+TPM is good enough to pass a CMMC2.0 compliance audit then that’s what the boss is going to care about. Since it doesn’t feel like that is good enough, further experiments with multifactor (non-OTP) windows login are over in that other thread I started.

1 Like

If you’re still looking at this, there are a few commercial options worth considering for Windows logon MFA. miniOrange is one I’ve come across that supports MFA for Windows login and can use methods such as TOTP/authenticator-based OTP, push, biometrics, and security keys. It may be worth comparing with ManageEngine ADSelfService Plus or JumpCloud, depending on whether you’re looking for something standalone or something that fits into an existing directory/endpoint setup.

One thing I’d check carefully is whether the specific deployment supports your local-login/offline requirement, since that’s a different use case from simply adding TOTP to web apps. For an environment where RDP is also important, I’d also verify how the MFA is applied to both console and RDP logons before choosing a product.

Thanks for those MFA options. This has been an “on again, off again” effort that I’m sure we’ll revisit in the future. It’s driven by a desire to be CMMC compliant, but it’s been awhile since we’ve bid on government/military contracts, so it’s been awhile since we’ve put effort into chipping away at our myriad shortcomings.

Basic Windows Hello might satisfy an audit, but I know full well a 6 digit pin is bogus security for physical access to a bitlockered machine, so personally I’m interested in requiring 2 inputs from the user, whenever the boss is interested in spending time and effort on IT/security again.