When Is MFA Really Required? Navigating CMMC, NIST, and Kerberos in Practice

Eric Marquette

Welcome back to CMMC Unlocked! I'm Eric, here with Paul Netopski and Roz the Rulemaker. Today, we’re going headfirst into one of the trickier topics in CMMC 2.0 compliance—when, where, and how to apply multifactor authentication, or MFA. But before we even get into the weeds on MFA, let's set the scene: what does identification and authentication actually mean in this context?

Paul Netopski

Absolutely. And Eric, this comes down to mapping out who—or what—is getting access in the environment, and how we verify those identities. If you look at the IA.xlsx mapping document, you see right up front that CMMC 2.0 Level 2, which is based on NIST SP800-171, calls for organizations to identify users, devices, and even processes. That’s IA.L1-3.5.1 and IA.L1-3.5.2. And each user, process, or device has to authenticate before touching organizational systems—so basically, no generic logins, no ghost devices sneaking in the backdoor. It’s all about accountability.

Roz the Rulemaker

And we have to distinguish between the different types of access: local access versus network access, and also privileged versus non-privileged accounts. NIST makes a big deal out of spelling these out. Local access is when you’re sitting at a device and logging in directly. Network access means you’re coming in over the wire—or WiFi—or even remotely through VPN or cloud. Privileged accounts? Think of your admins, not your everyday users. And every authentication event has to trace back to this policy. I once worked with a federal agency that structured their workflow so that every time a new device or user came online, they needed pre-approval and showed up in a central identity management system. No exceptions. That level of rigor made their audit process so much easier down the road.

Paul Netopski

Right, Roz. And if you check the NIST SP800-53 controls, there’s a clear lineage here. Because every assessment comes back to whether you can prove the who, what, and when behind access events. That’s the baseline. If you can’t answer that, you’re gonna have problems at audit time.

Eric Marquette

And just, for organizations, don’t forget that your Identification & Authentication Policy should actually reflect what’s happening operationally—not just what’s required on paper. It’s easy to miss that nuance if you’re just copying templates. We saw in previous episodes how config management and policy alignment really help when it comes time to show evidence, right?

Roz the Rulemaker

Exactly, Eric. Policy isn’t just a document—it’s a living workflow. If you lock in that operational rigor, everything else becomes much clearer, including when MFA should really come into play.

Paul Netopski

So, let's put a spotlight on control 3.5.3—this is the infamous one: use multifactor authentication for local and network access to privileged accounts, and for network access to non-privileged accounts. Which, if you haven’t spent way too many hours with the actual text, means admins get hit with stricter requirements than regular users, especially when it comes to local logins.

Eric Marquette

Yeah, and what’s wild is, not all MFA deployments are created equal. Some folks assume you need MFA literally everywhere and for everyone, which sounds secure, but in practice, that can tie your users in knots. So let’s dig into tech choices for a sec—Paul, what are you seeing in the field? Windows Hello for Business? Yubikey? DUO?

Paul Netopski

All of the above, Eric. Realistically, it’s often a mix. Windows Hello for Business is usually the go-to for admins on Windows environments, especially when tied to Active Directory. Yubikeys and FIDO2 tokens are great when you’ve got users hopping between machines, especially in high-security environments or if you want to air-gap credentials a bit. And then you've got DUO or similar services for layering MFA on top of remote desktop or web applications—important for those non-privileged users accessing over the network. But you gotta map this to the right events. I remember a contract where the client tried to bolt on MFA to every single system—local, remote, admin, user, print server, you name it. They thought more MFA equals better security, but it tanked productivity. And ironically, they failed their assessment because users started bypassing controls just to get work done. Sometimes too much strictness creates its own vulnerabilities.

Roz the Rulemaker

That's such a classic policy mistake—over-scoping. The key language in both NIST SP800-171 and your I&A Policy is that MFA is explicitly for privileged account local and network access, and for network access to non-privileged accounts. Not for every single touchpoint. Admins logging in directly to servers? Yes, enforce MFA. Regular users sitting down at their normal workstations? That’s not a requirement—unless they're accessing something remotely. Policies should delineate this cleanly to avoid unnecessary friction.

Eric Marquette

And let’s not forget, the more complex your MFA flow, the more help desk calls you’re gonna get. Sometimes simplicity is your best friend when it comes to sustainable compliance.

Eric Marquette

Alright, so here’s a hot-button issue—Kerberos. There’s a belief out there that “Kerberos is enough” for MFA, especially inside the LAN. Paul, you've probably heard this argument from clients who don't want extra MFA prompts everywhere, right?

Paul Netopski

Oh, all the time. The rationale is: once you do MFA at login and you’re authenticated, the Kerberos ticket acts as that ongoing proof of identity, and it supports replay resistance, since the tickets are time-bound and encrypted. NIST SP800-53 and CMMC guidance back this up: if you’ve already provided an MFA event at workstation login, you don’t have to keep re-prompting for each internal app as long as you’re not crossing privilege boundaries or jumping to remote resources. But you do need to rethink things when somebody is accessing resources remotely, like a cloud app or RDP into a server. That’s when another explicit MFA event is called for.

Roz the Rulemaker

What you want to avoid is “MFA fatigue”—where users get hammered with prompt after prompt until they start looking for shortcuts. I helped an agency design their workflow so that device registration required explicit approval, and they only enforced MFA when someone tried to access resources outside that pre-approved boundary. For routine internal movement, the Kerberos ticket was enough. For remote access, you got that fresh MFA challenge. That way, the policy aligns with both NIST best practices and user sanity.

Eric Marquette

We actually ran into this doing remote podcast production a while ago—I know, totally different stakes, but the same rules applied. We used device registration and only enforced MFA when accessing the system from approved remote locations. That was the only way to keep things secure without making the team miserable. And the CMMC assessment folks were happy as long as the process was documented and mapped to policy.

Paul Netopski

Exactly. Document how Kerberos is used for replay resistance, show that MFA is in place for privileged scenarios and remote access, and you’re gonna be on solid footing during an audit. It’s about demonstrating the intent and effectiveness, not just rigidly following checklists.

Eric Marquette

Let’s shift gears for a sec. What happens when you’ve got systems or devices with multiple people logging in—shared workstations, manufacturing floors, that kind of thing? Now MFA gets messy, right?

Paul Netopski

Yeah, this is a pain point. Every session, even on shared systems, has to be individually authenticated. NIST and the I&A Policy both require user-level authentication. So you can’t have a generic “shop floor” login anymore. Even with MFA, you have to make sure the person behind the keyboard matches the session, not just some MFA token lying around. Centralized solutions like Active Directory help by enforcing unique logins and tying each authentication event to an individual. If you can, integrate your MFA provider so sessions can be tracked and attributed to a single user each time.

Roz the Rulemaker

And then there’s session management. You’ve got to make sure that when people switch on the same device, previous sessions are closed, logged, and the new user gets prompted fresh. It’s not just about the login event; it's the lifecycle of the session. That’s where session timeouts and automatic logouts become really important—otherwise, compliance falls apart pretty quickly. I recommend regularly auditing your session logs for anomalies—like repeated MFA skips or generic accounts getting used—because that’s what an assessor is going to dig into.

Eric Marquette

There’s also a training component here. We touched on this in our awareness episode—if users don’t actually understand why unique sessions matter, they’ll find ways to subvert the system just to get things done faster. Tech and policy are only as good as the people using them.

Paul Netopski

Spot on, Eric. And don’t ignore your logs—audit everything from MFA challenge responses to who’s logging in, when, and from where. Pattern analysis is a goldmine for catching compliance or security gaps in these environments.

Roz the Rulemaker

Now, remote and cloud access—this is the landscape that’s changed the most in recent years. With more apps and data outside your four walls, it’s essential to get MFA right for anything accessed remotely, especially if it involves CUI or sensitive admin activity.

Paul Netopski

Exactly, Roz. For cloud apps and remote desktops, you need MFA with every session. The old “I logged into my laptop this morning, so I’m set for the day” doesn’t cut it if you’re now jumping into Office 365, AWS, or a cloud-based ERP system. Best practice? Integrate your MFA solution with VPNs, RDP gateways, and cloud identity providers—so every remote authentication gets challenged anew. And make sure that the prompts aren’t just arbitrary; they should be triggered by real risk—like new devices, odd hours, or admin actions.

Eric Marquette

Regular policy reviews are a must to keep up with the pace of change. I’ve seen organizations roll out MFA for everything cloud-related, but then six months down the line, business processes shift—new remote tools get adopted, or someone spins up a shadow IT project, and suddenly there’s sensitive data accessible without proper MFA. Schedule reviews every quarter, and make sure your policy—and your actual enforcement—match up. That’s one of the best ways to stay one step ahead, and it’s something we talked about recently in that Acceptable Use Policy episode. If your policies and technical controls don’t align, your compliance argument falls apart really quickly.

Paul Netopski

And don’t forget, the audit trail’s as important as enforcement. If you can’t show when and why MFA was triggered for a remote or cloud session, you’re going to get dinged. So integrate logging with your SIEM wherever possible.

Eric Marquette

So, you've put all this effort into deploying MFA... but how do you know it’s actually working? Monitoring and ongoing audits are where the rubber meets the road, honestly.

Paul Netopski

Absolutely. Start with continuous monitoring of your MFA logs. Look for patterns—repeated failed attempts, logins at weird hours, or devices coming in from outside normal geographies. Automated tools can help flag these events instantly. But the audit piece is just as critical. On a regular schedule, review every access point to confirm no one’s bypassing MFA, intentionally or otherwise. Sometimes policies drift as IT rolls out new applications or integrates legacy systems. That’s where periodic audits find the gaps before the DoD or your CMMC assessor does.

Roz the Rulemaker

And don’t just rely on technical measures—make sure you’ve got documented evidence that matches your policies. Automated compliance reporting is fantastic for showing point-in-time status, but also track remediation. If you find a non-compliant app during an audit, your remediation process should be swift and well-documented. When the assessor arrives, they want to see not just that you found issues, but that you fixed them promptly.

Eric Marquette

Alright, that’s going to wrap up today’s deep dive on the real-world complexities of MFA within CMMC and NIST frameworks. Roz, Paul—thanks as always for sharing your wisdom and keeping us, well, honest!

Roz the Rulemaker

Always a pleasure. And for all our listeners, remember: good policy breathes through continuous improvement and regular checkups—don’t just set it and forget it.

Paul Netopski

Couldn’t agree more. Stay vigilant, and don’t let policy drift sneak up on you. Until next time.

Eric Marquette

And that's it for this episode of CMMC Unlocked. We’ll see you next time—keep those controls tight, and your MFA tighter. Goodbye everyone!