Notifications
Clear all
Topic starter
12/07/2026 12:16 pm
TL;DR: NIST SP 800-63B defines MFA as two different factor types, warns against SMS OTP for high-assurance use, and requires device-bound biometrics plus reauthentication for sensitive transactions, according to eMudhra. The practical issue is not whether MFA exists, but whether its factors, binding, and logging satisfy assurance expectations that many programmes still approximate.
NHIMG editorial — based on content published by eMudhra: NIST-compliant MFA under NIST SP 800-63B and related compliance expectations
By the numbers:
- 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.
- Only 5.7% of organisations have full visibility into their service accounts.
Questions worth separating out
Q: How should security teams implement MFA for privileged accounts?
A: Security teams should require phishing-resistant MFA for privileged accounts, especially where remote administration or high-impact systems are involved.
Q: Why do SMS and email OTP methods fall short for high-assurance access?
A: They rely on channels that are easier to intercept, redirect, or recover than the account being protected.
Q: What signals show that MFA is working as intended?
A: Look for evidence that the second factor is independent, device-bound where required, and enforced on sensitive transactions rather than only at initial login.
Practitioner guidance
- Map every login flow to factor classes Review whether each authentication path uses two genuinely different factor types and remove flows that only stack knowledge factors or mailbox-based verification.
- Retire SMS OTP from high-assurance use cases Limit SMS OTP to low-risk scenarios and replace it for sensitive systems with stronger methods such as authenticator apps, hardware tokens, or device-bound push approvals.
- Bind biometrics to trusted devices Use biometrics only when they are coupled to device-held cryptographic proof and an additional possession or PIN factor.
What's in the full article
eMudhra's full article covers the implementation detail this post intentionally leaves for the source:
- Step-by-step guidance on which MFA methods eMudhra maps to NIST expectations.
- Examples of how the vendor positions MFA across PCI DSS, HIPAA, ISO 27001, and Kenya's Data Protection Act.
- Implementation notes for federated authentication with SAML, OAuth2, and OpenID Connect.
- Product-level detail on audit dashboards and device-bound MFA options.
👉 Read eMudhra's guide to NIST-compliant MFA methods and controls →
NIST-compliant MFA: are your authentication controls keeping up?
Explore further
12/07/2026 12:30 pm
MFA is an assurance model, not a checkbox control. NIST SP 800-63B makes the distinction between a second prompt and a second factor explicit, which is why many enterprise deployments overstate their actual assurance level. If the second step uses the same factor class or the same compromised trust boundary, it does not materially change the access risk. Practitioners should treat factor independence as the real control objective.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to NHI Mgmt Group research.
A question worth separating out:
Q: Who is accountable when MFA does not meet NIST expectations?
A: Accountability sits with the identity, security, and risk owners who approved the authentication design and its exceptions. If a low-assurance method remains in a high-risk flow, the issue is governance, not user behaviour. Teams should align policy, audit evidence, and exception review so the control can be defended before regulators or customers.
👉 Read our full editorial: NIST-compliant MFA is a control baseline, not a feature add-on
