NIST SP 800-171 revision 4?

---

Transcript

Jacob: All right, folks. It is August of 2026, and I’ve got a question for you. How familiar are you with NIST Special Publication 800-63B-4, Digital Identity Guidelines for Authentication and Authenticator Management? Because according to the DoD CIO’s new “brilliant at the basics” campaign, you’d better get real comfortable with all 130 pages — because the multifactor authentication solution you’ve been using probably isn’t going to cut it anymore. As it turns out, the DoD CIO’s “brilliant at the basics” ain’t so basic after all. And that’s what we’re going to talk about today.

Jason, riddle me this, buddy. We’re supposed to be reducing cost and burden — that’s the whole reason we went through this Phase 2 suspension. But the DoD CIO’s list of basics are not only more advanced than the existing requirements that people were struggling with, but they would be, in a lot of ways, a huge expansion of what is currently required.

Jason: I’ve got to correct you, first and foremost. We’re supposed to reduce the cost and burden for small and medium-sized businesses to make their way in there. And what’s characteristic of small and medium-sized businesses? Not a lot of people that are familiar with NIST 800-171, or NIST documents in general. A lot of people that are double-dipping in their roles to achieve CMMC compliance, or whatever compliance regulatory framework they have to adhere to. So, you know what better way to make this easier than give them another document that they’re going to have to translate, right?

Jacob: There you go. There you go. We’ll see. For those of you not familiar: if you read the press release that came out in mid-July about the suspension of CMMC Phase 2, and you scroll all the way to the bottom — or if you watch the DoD CIO’s video about the suspension — they talk about the “brilliant at the basics” campaign, which claimed to be, quote, “designed to empower the DIB, particularly small and midsize businesses, by distilling vital cybersecurity principles into clear, actionable steps for IT environments.” There’s been lots of talk about removing “compliance burdens” — their words — and “administrative barriers” — their words — around these requirements by suspending CMMC. That implies that if it weren’t for those pesky third-party verification assessments, then the DIB would be unleashed to implement these basic cybersecurity requirements.

Jason: Right. And the DIB would have been motivated to implement these basic cybersecurity requirements for the past 20 years, when CISA has been recommending it to combat threats, right? There’s nothing that says that this time around we’re just going to do it the right way. “Just get out of the way so we can implement these basics.”

Jacob: Let’s talk about it. We don’t have time in this episode to get into all of them, because there’s 20 of them, including OT requirements — more on that in a future episode, like and subscribe. We don’t have to go very far, everybody. Let’s look at the very first basic cybersecurity control that the DIB is now free to implement, because they don’t have to worry about those pesky CMMC third-party verification assessments for the time being. Number one: phishing-resistant multifactor authentication. The “brilliant at the basics” document says: “Upgrade your authentication mechanisms to require strong, phishing-resistant MFA methods for user accounts. Moving away from legacy MFA methods such as SMS text messages or push notifications, [this is] the foundation of a modern security stack. By combining explicit identity verification with least privilege principles, you minimize the utility of compromised credentials and significantly reduce the risk of unauthorized access to sensitive systems.”

All of that is true. Phishing-resistant MFA is a wonderful security solution — we’re going to talk about it. Nothing they said is false. But in case you aren’t up to speed on your NIST publications: phishing resistance is not a buzzword. This is not marketing. Everybody knows that, per NIST Special Publication 800-63B-4, phishing resistance is “the ability of the authentication protocol to prevent the disclosure of authentication secrets and valid authenticator outputs to an impostor verifier without reliance on the vigilance of the claimant.” Right — rolls right off the tongue. That’s what phishing resistance is.

And if you’re thinking to yourself, “But NIST SP 800-171 only talks about replay-resistant authentication” — you’re right, because also per NIST SP 800-63B-4, replay resistance is completely different from phishing resistance. Replay resistance, the current requirement, is “the property of an authentication process to resist replay attacks, typically by the use of an authenticator output that is only valid for a specific authentication.” Let’s get into some examples, because all that sounds like Greek. Okay — you need to read 800-63B. Trust me, you need to get very familiar with what this is. But essentially, replay resistance says a stolen answer can’t be used twice — like a text-message code that you got for your multifactor authentication. Phishing resistance says the bad guy can’t trick you into giving them a usable answer at all.

So here’s an example — stick with me. Imagine you have a one-time-use lunch ticket at school, and somebody steals the ticket that you used yesterday and hands it to the lunch lady. The lunch lady says, “Sorry, this code’s been used already. No lunch for you.” That’s replay resistance — they can’t replay the code that you already used. Pretty straightforward. Now, imagine the lunch lady is an impostor, and she wants to steal your lunch by stealing your lunch code. If you give her your ticket, they phished you — they tricked you into thinking they were the real lunch lady, and you gave them your valid code. But pretend that your lunch code is now a magical ticket, and it’s going to check if the lunch lady is an impostor — and if she is, refuse to work with her. That’s phishing resistance. Replay resistance, phishing resistance — not the same thing.

SP 800-171, even through Revision 3 — so even up through 800-171 Revision 3 — requires multifactor authentication, requires replay-resistant authentication, but not even necessarily at the same time. Replay resistance has nothing to do with whether the authentication is single-factor or multifactor. So you can fail multifactor authentication requirements and still meet replay-resistant authentication requirements — you have single-factor replay resistance. It’s a property of the authentication protocol; it’s not the number of factors that makes something replay-resistant. So here’s another problem: not every replay-resistant authenticator is phishing-resistant, because they are different things. So even if you’re using replay-resistant multifactor — which is not the current requirement, even through 800-171 Rev 3 — chances are it’s not going to cut it for this new thing that the DoD CIO wants.

Jason: Which is crazy, because when I think about “brilliant at the basics,” I think about John Madden, right? You’ve got to get back to the blocking and tackling, the boom, the pow — you’ve got to hit the gap and take the ball up the field. And with that being said, everything you just described to me sounds like this is much more complicated, much more burdensome. It’s definitely much more secure, but it’s going to—

Jacob: Yeah, it’s going to take much more to implement.

Jason: And this is one of the basics that people were struggling with, right?

Jacob: Well, apparently not. Apparently the problem was the third-party assessments that were keeping people from being able to do this — because if we don’t make them do the third-party assessments, then we can ask them to do this. So it not only is different, and a more advanced concept, but by saying that it needs to be phishing-resistant MFA, you are limiting the number of options that people could use to meet that requirement. So let’s just very briefly — you really need to read 800-63B, everybody. Sorry to ruin your summer plans, but you thought 800-53 was a bummer? Wait until you see where 800-53 gets its ideas from.

Anyways, let’s talk about what’s phishing-resistant and what’s not. Passwords: not replay-resistant, not phishing-resistant. Recovery codes: replay-resistant, not phishing-resistant. SMS one-time passwords: replay-resistant, not phishing-resistant. Voice-based one-time passwords — like, “Hey, we’ll call you instead of texting you”: replay-resistant, not phishing-resistant. Authenticator apps that have time-limited one-time passwords, through certain keys and things like that: replay-resistant, not phishing-resistant. Hardware token one-time passwords, if you invested in that kind of a system: replay-resistant, not phishing-resistant. This is explicitly explained in 800-63B. They’re very clear about what is phishing-resistant and what is not. And some of the only things they list as being phishing-resistant are things like PIV cards and CAC cards, which are both replay-resistant and phishing-resistant thanks to something known as channel binding — read 800-63B, I won’t bore you with the details — or things like WebAuthn/FIDO2 security keys and passkeys, which are also replay-resistant and phishing-resistant through something known as verifier name binding. Read the special publication; I’m not going to explain the details, because everybody will stop watching.

There aren’t very many authentication solutions that people think of when they think of multifactor authentication solutions that would meet the requirement to be phishing-resistant. It is a great idea from a security perspective. This is not a basic thing to do. It might be the basic thing to do for, I don’t know, the CISO of a Fortune 500 company for their entire career. It ain’t basic for the small and medium-sized businesses in the DIB.

Give you some quick examples from Microsoft. Passwords: not multifactor, not replay-resistant, not phishing-resistant. Something like a password plus Microsoft Authenticator’s six-digit time-based one-time password: that’s two factors, it’s replay-resistant, not phishing-resistant. Windows Hello for Business: probably good. Passkeys: probably good. FIDO2 security keys: probably good. Do you have those deployed in your enterprise? Probably not.

Jason: So aside from Windows Hello for Business, the entire list — both of those lists that you just read off — of the acceptable things… The small and medium-sized business, the audience for this change, or the suspension, to address the common hiccups for them — I don’t see this deployed by any of them. This isn’t the method they go to. This isn’t the method they can manage. These are all enterprise-size — full IT teams, full managed teams, and everything like that. Not mom-and-pop machine shops walking around with FIDO keys.

Jacob: Jason — basics, man.

Jason: It’s the basics — but they’re saying “brilliant at the basics.” So are we going to be the best blockers or the best tacklers after things like that? MFA is a basic control.

Jacob: Allegedly, these are the basics. This is the first one.

Jason: Phishing- and replay-resistant combo is not the basic. That’s more like the Texas stunt, right? Like, we’re not learning how to charge the—

Jacob: Don’t forget — we didn’t even talk about this, but don’t forget that whenever you read through what they’re talking about (this is a completely separate episode), “by combining explicit identity verification with least privilege principles” is what they’re talking about. That’s another combination of existing separate requirements into a combo requirement. So not only do I have to have phishing-resistant MFA — instead of phishing resistance and MFA — but now I also have to integrate things with least privilege dynamically. That’s what you should do. That is wonderful. That is not a basic thing to do. And that’s not what the current requirements that people are struggling with currently say. This changes and expands and combines and makes those requirements dramatically more difficult — complicates that requirement for people to figure out, the “Sum IT Up” word.

Jason: Well, talk about reducing burden on the DIB. Can you just ask yourself: can your business application support phishing-resistant multifactor authentication? Does your ERP system support phishing-resistant multifactor authentication? Better call Epicor. And you better get real familiar with Dynamics 365, because there’s not a lot of options out there if you’ve got legacy systems. If I had a penny for every single time somebody was like, “Every time we turn on MFA on this piece of OT, it breaks”—

Jacob: Well, that — we’ll get to that in a little bit, in terms of the user resistance to MFA at all, whether or not it’s a certain form of MFA. But let’s get to this other idea. Okay, we’ve said this multiple times: this is great for security. Objectively, this is a real deal, very good security recommendation. So why isn’t it already a requirement? If it’s so great, why wasn’t it the requirement all along?

Okay, a little bit of history here. Replay-resistant authentication has been a NIST SP 800-53 security control since Revision 3 of NIST SP 800-53. A bunch of the IA family of security controls in 800-53, and their enhancements, reflect the guidance in NIST SP 800-63. 800-63 has been around for 20 years, talking about authentication security guidance, protocols, structures, things like that. That guidance is captured in controls in the 800-53 catalog. When 800-63 was updated to include replay resistance, subsequent 800-53 revisions — from 800-53 Rev 3 and forward — followed with that guidance and included it in the control catalog. 800-53 Revision 5 was the last update, in 2020. 800-63 was last updated in 2025. And that was the first time that they mentioned phishing-resistant authentication. So phishing resistance as a security control won’t show up until 800-53 Revision 6. It literally doesn’t exist as an 800-53 control. And you can look this up for yourself. Go right now to the NIST glossary and scroll down to “phishing resistance.” There’s no citation for 800-53. The only citation is 800-63, because 800-53 hasn’t been revised to match the newest NIST guidance across a bunch of different special publications. But only once it’s in 800-53 would it then potentially be eligible for inclusion — brace yourselves, folks — for inclusion in the 800-171 Revision 4 baseline. The reason that we went from 800-171 Rev 2 to 800-171 Rev 3 was because we went from 800-53 Rev 4 to 800-53 Rev 5. So now you’re saying that this control will one day show up in 800-53 Rev 6, and then it could potentially show up in 800-171 Revision 4 derived from 800-53 Rev 6. Until then, how exactly would this obviously basic, 101 blocking-and-tackling requirement be included in a contract? It doesn’t even exist in the 800-53 catalog. Does anybody know the criteria for determining how you would meet this, if NIST hasn’t developed the criteria for knowing how you would meet this requirement? The very first “brilliant basic” requirement is literally accelerating DIB contractor requirements straight past 800-171 Revision 3 — which they’re not even on yet — before the requirement could even be included in federal control baselines, because it doesn’t exist in 800-53.

Jason: So I’m quickly looking up something, because I want to see — and I don’t think it’s true, but — is there an ODP assigned to the MFA control for 800-53, or for Rev 3?

Jacob: Well, this is the thing. We’re in the middle of the review, and according to the DoD, all Rev 3 ODPs are under review. So maybe they could specify an ODP to say “phishing resistance.” That would be very interesting to do, because you would again be accelerating the 800-171 baseline, derived from 800-53, past the revision cycle of 800-53 — which, don’t get me wrong, props to you guys. That is a very innovative way of defeating the slow revision cycle that NIST is on. Congratulations, DoD CIO — you have solved the puzzle for being able to include things that NIST doesn’t even include in their own baseline. But what about that whole part about reducing cost and burden? That’s super cool, but this ain’t basic.

Jason: Yeah, everything you’ve mentioned thus far — and just to double-check, I don’t think there is an ODP assigned to that control, so they wouldn’t even be able to plug in afterwards. So you’re right — that revision is further down the line, and you’re talking about immediate impact, which is what this program is supposed to accomplish. How are we putting it out there? How are we determining if it’s done?

Jacob: We’re in August right now. RFI responses are due mid-August, and then at the end of September, at the end of the review of the reform task group, we’re supposed to figure out what the recommendations are. Are they going to be recommending this? Are they going to be telling NIST, “Hey, we really, really, really want phishing-resistant MFA, because it’s the best security choice”? How do you square that with this idea that you were going to be saving everybody a bunch of time and money? We haven’t even gotten to the other “brilliant at the basics” items in the IT domain, to say nothing of the fact that there’s another 10 of them in the OT domain, which we’ve briefly talked about.

But let’s just wrap this up with this idea. Telling people that they need to go to phishing-resistant multifactor authentication is more than just specifying an upgrade to existing requirements that have been there for 10 years. Because the DIBCAC top 10 “other than satisfied” security controls — the ones they reported after more than a hundred in-person assessments — list out the controls that defense contractors aren’t currently implementing. And the number two most common requirement that people aren’t doing at all is multifactor authentication. Replay-resistant, phishing-resistant — the most vanilla, basic, 101, “just please turn on MFA at all” is the number two most common thing that DIBCAC sees. That requirement has been there for 10 years, and contractors aren’t implementing any form of MFA, even when it doesn’t have to directly be even replay-resistant, to say nothing of phishing resistance. So now we’re telling them to jump all the way to phishing-resistant MFA at the same time, while claiming to be reducing cost and burden. I mean, tell us in the chat — am I taking crazy pills here?

Jason: I’m not in the chat — I’m just directly across from you. It’s amazing. However, you’re not taking crazy pills. When the DIBCAC top 10 was released, one of the things I personally did was start comparing the CISA alerts — and what was being put on them — to what was appearing on there. What is the biggest thing compared to the threats, right? And as we went through that, not only did we discover that people were failing to implement it, but then — was it Nick Del Rosa? — gave the presentation at one of our events, where he gave the deeper explanation: it was that organizations just aren’t fully understanding what it means to implement MFA. “We just don’t understand this. We think that we have it in this one place.” It wasn’t just that it wasn’t sufficiently placed throughout the scope — it wasn’t adequately implemented in the places it was put.

Jacob: So, but now we’re telling them we’re going to make it easier — we’re going to eliminate the tape, except now what you’ve put is more requirements without verification from third parties, and more capability for people to mess up. First of all, to Nick Del Rosa’s point, this was also found in GAO’s independent reporting of the ecosystem — they found that companies just don’t know how to do this stuff. It doesn’t matter if you give them — obviously 10 years — give them 15, give them 20. They don’t know how to do it. This is essentially the same thing as being like, “We’re going to raise taxes, but we’re not going to close any tax code loopholes.” Like, okay — you could raise the taxes as high as you want. If you don’t close the loopholes, people ain’t paying it. It’s like, okay — people aren’t doing MFA. We have no idea if they’re doing MFA without third-party verification. So now, “do a much more advanced and expensive version of MFA, but we’re still not going to ask for any proof.” Like, “we’re going to raise the tax, we’re not going to close the loophole.” Amazing job from a policy perspective.

Jacob: So, just to get to some closing thoughts here: the DoD suspended Phase 2 of the CMMC rollout to reduce the burden on defense contractors struggling to meet existing cybersecurity requirements that haven’t changed in 10 years. So why is the DoD simultaneously signaling that contractors need to meet much more advanced, costly, and burdensome cybersecurity requirements? I don’t know what’s coming out of this program review that they’re doing, but I have a distinct feeling that while the DoD is over here struggling to figure out what they’re going to do about third-party assessment mechanisms, everybody’s cybersecurity requirements are about to get a lot harder.

Jason: So, do you remember, in Blades of Glory, when it was like, “Nobody knows what it means, but it’s provocative”? That’s what this feels like. “Phishing-resistant MFA.” Nobody in the DIB that is going to have to apply this — the ones you were limiting burden on — is going to be like, “I know exactly what that means, let’s go get to it.” It didn’t happen with regular MFA.

Jacob: Hey, I’ll tell you what — we love helping people with phishing-resistant MFA. Well, this wasn’t our idea; we’re just trying to help people turn on MFA at all. So if you’d like to know about how to comply with phishing-resistant MFA requirements, you’d better call us — or you’d better get real familiar with 800-63B, this other NIST publication that no one’s ever read.

Jason: I love how, throughout the episode, you were like, “Everybody knows about 800-63, right?”

Jacob: Of course. It’s basic.

Jason: It’s right on my nightstand.

Jacob: You know about impostor verifiers, and the legitimacy of claimants, and authentication binding. Yeah, of course. Anyways, this is just the first one of 20 of the basics that we’re talking about, and there’s a lot more to talk about the further down into this document that you get. So make sure that you like and subscribe, because we’ve got a lot of work to do, apparently — and it ain’t so basic. So, we’ll see you next week.

Jason: See you next week, folks.