The DoD's "Basic" Cybersecurity Isn't Basic at All

Summary

---

Podcast Summary: "The DoD's 'Basic' Cybersecurity Isn't Basic at All"

Sum IT Up: CMMC News Roundup – August 6, 2026
Host: Summit 7
Main Theme:
An in-depth, no-nonsense analysis of the Department of Defense (DoD) CIO’s "Brilliant at the Basics" campaign, highlighting how the so-called basic cybersecurity controls—especially around phishing-resistant multi-factor authentication (MFA)—are far from simple for most defense contractors, particularly small and mid-sized businesses. The hosts dissect the evolving requirements and their real-world feasibility.

---

Episode Overview

The hosts unpack the DoD's shift in cybersecurity requirements following the CMMC Phase 2 suspension, focusing on the "Brilliant at the Basics" campaign. The campaign claims to simplify and empower smaller defense contractors with clearer, actionable security steps, but the episode argues these "basics" are in fact advanced, costly, and difficult to implement.

---

Key Discussion Points & Insights

1. The "Brilliant at the Basics" Campaign is Anything But Basic

• The DoD's new baseline for contractors involves advanced NIST standards, notably SP 800-63B (Digital Identity Guidelines).
• The hosts highlight the expectation that contractors now get familiar with "all 130 pages" of NIST 800-63B-4, as legacy MFA likely won’t suffice.
• Quote [00:00]:

  "The multi factor authentication solution that you've been using probably isn't going to cut it anymore... the DOD CIO's brilliant at the basics ain't so basic after all." – Host A

2. Burden on Small and Medium Businesses (SMBs)

• The intended reduction in compliance burden for SMBs appears contradicted by these sophisticated new controls.
• Most SMBs lack in-house NIST expertise and multi-role staff are overwhelmed.
• Quote [01:05]:

  “What better way to make this easier than give them another document that they're going to have to translate?” – Host B

3. Deep Dive: Phishing-Resistant Multi-Factor Authentication (MFA)

• The DoD's first "basic" control is to require strong, phishing-resistant MFA for all user accounts—eschewing SMS, push notifications, and most other common methods.
• The hosts clarify the difference between "replay-resistant" (current requirement) and "phishing-resistant" (new DoD ask) authentication:
  • Replay-resistant: Prevents re-use of an authentication code (e.g., one-time-use lunch ticket analogy).
  • Phishing-resistant: Actively blocks attackers from ever obtaining a usable authentication secret, even if the user is tricked (magical lunch ticket that rejects imposters).
• Quote [04:42]:

  "Phishing resistance is not a buzzword. This is not marketing... Per NIST Special Publication 863-4, phishing resistance is the ability of the authentication protocol to prevent the disclosure of authentication secrets to an imposter verifier without reliance on the vigilance of the claimant." – Host A

4. Examples: What’s In and What’s Out

• Quickly runs through what counts as phishing-resistant:
  • Not phishing-resistant: Passwords, recovery codes, SMS/voice/OTP apps, hardware tokens with one-time codes.
  • Phishing-resistant: PIV/CAC cards (via channel binding), FIDO2/WebAuthn security keys, “passkeys."
• Quote [09:28]:

  "There aren't very many authentication solutions that people think of when they think of multi factor authentication...that would meet the requirement to be phishing resistant...It ain't basic for the small medium sized businesses." – Host A

5. Enterprise-Ready vs. SMB Reality

• The suggested solutions are typically used by Fortune 500s or those with full IT teams—"not mom & pop’s machine shop."
• Quote [11:24]:

  "...the entire list of both of those lists that you just read off of the acceptable things...I don't see this deployed by any of them. Not mom and Pop's machine shop are walking around with Fido keys." – Host B

6. Cascading Complexity – Combining and Expanding Requirements

• "Phishing-resistant MFA" is combined with least-privilege access requirements—a sophisticated “combo” that multiplies implementation difficulty.
• Quote [12:16]:

  "That's another combination of existing separate requirements into a combo requirement...That is not a basic thing to do." – Host A

7. Technical and Practical Blockers

• Most existing business and ERP systems don’t support phishing-resistant MFA, especially legacy platforms.
• On the OT (Operational Technology) side, even basic MFA regularly “breaks” equipment.
• Quote [13:30]:

  "Does your ERP system support phishing resistant Multi Factor Authentication? Better call Epicor and you better get real familiar with 365 dynamics because there's not a lot of options out there if you've got legacy systems." – Host A

8. Why Isn’t This the Requirement Already? (It's Not in the Standards)

• Phishing-resistant MFA isn’t even in NIST 800-53 Rev 5—it was only added to draft NIST 863 in 2025, and won’t be part of 800-53 until Rev 6 (future).
• New CMMC requirements are thus ahead of NIST/DFARS—there is no control currently to cite.
• Quote [15:09]:

  "...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..." – Host A

9. Verification Loopholes Make Controls Toothless

• Even with new, tough requirements, with third-party assessment suspended, there's no structured verification contractors are really complying.
• Quote [21:33]:

  "We're going to raise the tax. We're not going to close the loophole. Amazing job from a policy perspective." – Host A

10. Widespread Lack of Understanding and Implementation

• GAO and DIBCAC reports show most contractors still fail to implement any MFA correctly.
• New requirements, as explained by industry events and CISO briefings, will make compliance harder, not easier, for companies who couldn't get even the basics right so far.

---

Notable Quotes & Memorable Moments

• "Just get out of the way so we can implement these basics." (A, [02:51])
• "Phishing resistance is not a buzzword... Rolls right off the tongue." (A, [04:42])
• "Not mom and Pop's machine shop are walking around with Fido keys." (B, [11:24])
• "That's another combination of existing separate requirements into a combo requirement." (A, [12:16])
• "This is objectively a real deal security recommendation... But how are we putting it out there?" (A, [18:33])
• "Nobody knows what it means, but it's provocative... that's what it feels like. Phishing resistant MFA." (B, [23:06])
• "It's basic. It's right on my nightstand." (B, [23:54])

---

Key Timestamps

• 00:00–01:35: Episode Introduction & SMB compliance burden
• 02:35–07:41: Deep dive: Phishing-resistant MFA vs. replay-resistant MFA (explained with memorable “lunch ticket” analogy)
• 09:28–12:16: What authentication methods actually qualify? Why this isn’t "basic"
• 13:03–13:37: Feasibility for business and legacy systems
• 15:09–18:33: Current vs. future standards; phasing in new requirements before NIST supports them
• 19:27–21:33: DIBCAC Top 10 & GAO reports: widespread misunderstanding/failure to implement MFA
• 23:06–24:22: Policy contradictions and closing remarks

---

Tone and Takeaways

The hosts use humor and directness to underscore the disconnect between policy language ("empowering basics") and technical/operational reality for most defense contractors. While they acknowledge the security value of phishing-resistant MFA, they emphasize how premature and impractical it is to expect widespread near-term compliance among SMBs—especially with no clear guidance or verification process in place.

Their advice:
If you’re a contractor, especially SMB, prepare for a steeper climb and get real familiar with NIST SP 800-63B. And if you need help, call the experts—because these "basics" are far from basic.

---

Transcript

[A]

All right folks, it is August of 2026 and I got a question for you. How familiar are you with nist Special Publication 863 Bravo 4 Digital Identity Guidelines for Authentication and Authenticator Management? Because According to the DOD CIO's new Brilliant at the Basics campaign, you better get real comfortable with all 130 pages because the multi factor authentication solution that 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 why we went through this phase two 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.

[B]

I gotta 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, in their roles to achieve CMMC compliance or whatever compliance regulatory framework that they have to adhere to. Right. So you know, what better way to make this easier than give them another document that they're going to have to translate? Right?

[A]

I mean, there you go, There you go. I mean we'll, 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 down 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 mid sized businesses by distilling vital cybersecurity principles into clear actionable steps for IT environments. There's lots of talk, 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 DIV would be unleashed to implement these basic cybersecurity requirements. Right? Right.

[B]

And the DIV would have been motivated to implement these basic cybersecurity requirements for the past 20 years when CISA was recommended to complete threats. Right? Like that. There's nothing, there's nothing that says that this time around we're just going to do it the right way, right?

[A]

Just get out of the way so we can implement these basics. 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 Multi Factor 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 notification forms 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 that 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. This is not a buzzword. Everybody knows that. Per NIST Special Publication 8634 Phishing resistance is the ability of the authentication protocol to prevent the disclosure of authentication secrets and and valid authenticator outputs to an imposter 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 SP801.71 only talks about replay resistant authentication. You're right, because Also per NIST SP863 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 863. 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 multi factor authentication. Phishing resistance says the bad guy can't trick you into giving you. Into giving them a usable answer at all. So here's an example. Stick with me here. 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 that the lunch lady is an imposter and she wants to steal your lunch by stealing your lunch code. If you give them your ticket, they fished you, they tricked you into thinking that 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 that's going to check if the lunch lady is an imposter and if they are, refuse to work with them. That's phishing resistance. Replay resistance. Phishing resistance. Not the same thing. SP801, 71 even through 8 revision 3. So even up through 171. Revision 3 requires multi factor authentication, requires replay resistant authentication, but not even necessarily at the same time. Replay resistance has nothing to do with whether or not the authentication is single factor or multi factor. So you can fail multi factor 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 make 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 multi factor, which is not the current requirement, Even even through 171 Rev3, chances are it's not going to cut it for this new thing that the DoD CIO wants.

[B]

Which is crazy because when you think about brilliant to basics, I think about John Madden, right? And you got to get back to the blocking and tackling, the boom, the pow, right? You got to hit the gap and take the ball up the field, right? So with that being said, everything that you just described to me sounds like that this is a much more complicated, much more burdensome, it's definitely much more secure. But it definitely, yeah, it's going to take much more to implement and I, I just. This is one of the basics that people were struggling with, right?

[A]

Well, apparently not. Apparently the problem was the third party assessments that was 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 I mean it, 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, very briefly, you really need to read 863 everybody. Sorry to ruin your summer plans, but you thought 853 was a bummer. Wait until you see where 853 gets its ideas from. Anyways, let's talk about what's phishing resistant and what's not. So passwords not replay resistant not phishing resistant Recovery codes those are 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 like 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 863. They're very clear about what is phishing resistant and what is not phishing resistant and some of the only things that they list as being phishing resistant are things like PIV cards and CAC cards which are both replay resistant and phishing resistant thing thanks to something known as channel binding. Read 863 I won't bore you with the details or things like web auth fido 2 security keys and pass keys those are also replay resistant and phishing resistant through things known as verifier name binding. Read the special publication not going to explain to you the details because everybody will stop watching. There aren't very many authentication solutions that people think of when they think of multi factor 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 Fortune 500 companies for their entire career. It ain't basic for the small medium sized businesses in the dip. Give you some sort of quick examples real quick from Microsoft right? So passwords is not multifactor, it's not replay resistant, it's not phishing resistant. Something like a password plus Microsoft authenticators 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 FIDO 2 security keys probably good. Do you have those deployed in your enterprise?

[B]

Probably not so aside from Windows, hello for business, the entire list of both of those lists that you just read

[A]

off

[B]

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 in which they go to. This isn't the method in which they can manage. These are all enterprise size, full. Like we have full ID teams, full managed teams and everything like that. Not mom and Pop's machine shop are walking around with Fido keys.

[A]

Jason. Basics, man.

[B]

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.

[A]

Allegedly. These are the basics.

[B]

This is the first fishing and replay resistant COM combo is not the basic. That's more like the. The Texas stunt. Right? Like we're not learning how.

[A]

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 identification 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.

[B]

Complicates that requirement for people to figure out the sum it up word.

[A]

Well, talk about reducing burden on the dib. Can can just ask yourself, can your business applications support phishing resistant Multi factor authentication? Does your ERP system support phishing resistant Multi Factor Authentication? Better call Epicor and you better get real familiar with 365 dynamics because there's not a lot of options out there if you've got legacy systems.

[B]

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.

[A]

Well that. That's. We'll get to that in a little bit in terms of like 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 a. This is great for security. Objectively this is a real deal. This is very good security recommendation. So why isn't it already a requirement? Right? 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 SP853 security control since revision three of NIST SP853. A bunch of the IA family of security controls in 853 and their enhancements reflect the guidance in NIST SP 863. 863 has been around for 20 years talking about authentication, security guidance protocols, structures, things like that. That guidance is captured in Controls in the 853 catalog. When 863 was updated to include replay resistance. Subsequent 853 revisions from 53 rev3 and forward followed with that guidance and included it in the Control Catalog. 853 revision 5 was the last update in 2020. 863 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 853 revision 6. It literally doesn't exist as an 853 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 853. The only citation is 863 because 853 hasn't been revised to match the newest NIST guidance across a bunch of different special publications. But only Once it's in 853 would it then potentially be eligible for inclusion. Brace yourselves folks, for inclusion in the 800171 revision 4 baseline. The reason that we went from 171 Rev 2 to 171 Rev 3 was because we went from 853 Rev 4 to 853 Rev 5. So now you're saying that this control will one day show up in 53 Rev6 and then it could potentially then show up in 800171 revision 4 derived from 53 Rev6. 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 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 800171 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 853.

[B]

So I'm quickly looking up something because I want to see and I don't think that it's true, but is there an ODP assigned to the MFA control for 53 or for Rev3?

[A]

Well, this is the thing. We're in the middle of the review and According to the DoD, all Rev3 ODPs are under review. So maybe they could specify an ODP to say, fishing resistance. That would be very interesting to do that because you would again be accelerating the 171 baseline derived from 53 past the revision cycle of 853. Which, don't get me wrong, props to you guys. I mean 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. What about that whole part about reducing cost and burden? Like that's super cool, but this ain't basic.

[B]

Yeah, everything that you've mentioned thus far and just to double check, I don't think that 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 is what this program is supposed to accomplish. I mean, how are we putting it out there? We're in our determine if it's done.

[A]

We're in August right now. RFI responses are due mid August and then we're supposed to at the end of September, at the end of the review of the Reform Task group, 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 sort of wrap this up with this idea here. Telling people that they need to go to Phishing Resistant Multi Factor 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.

[B]

Attaboy.

[A]

They report that they reported after more than 100 in person assessments lists 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?

[B]

I, I'm not in the chat, I'm just directly across from you. However, you're not taking crazy pills. When The DIBCAC top 10 was released, one of the things that I personally did was started comparing the CISO alerts and what was being put on them to what was appearing on there. What is the biggest thing to compare the threats? Right. And as I we went through that, not only did we discover that people were failing to implement it, but then we had was it Del Roso gave the presentation at one of our events where when he gave the deeper explanation it was 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. So but now we're telling we're going to make it easier, we're going to eliminate the tape. Except for now what you put is more requirements without verification from third parties and more capability for them for people to mess up.

[A]

I mean, you know, first, first of all, to Nick Delrosa's point, this was also found in GAO's independent reporting of the ecosystem was that they found that companies just don't know how to do this stuff. It doesn't matter if you give them obviously 10 years is give them 15, give them 20. They don't know how to do it. They don't know how to do it. Right. 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, like you could raise the taxes as high as you want. If you don't close the loopholes, people ain't paying it right. 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. So just to get to some closing thoughts here, right, the DoD suspended phase two 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 burden them 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.

[B]

So do you, do you remember on Blades of Glory when it was like, I don't. Nobody knows what it means, but it's provocative. Like, that's what it feels like. Fishing resistant mfa. Nobody in the dib that is going to have to apply this that you are limiting burden on is going to be like, I know exactly what that means.

[A]

Let's go get to.

[B]

Didn't happen with regular mfa.

[A]

Hey, I'll tell you what. We, we love helping people with fishing resistant mfa, but 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 better call us or you better get real familiar with 863, this other NIST publication that no one's ever read.

[B]

So I love how like throughout the, throughout the episode you were like, Everybody knows about 863. Right?

[A]

It's basic.

[B]

It's right on my nightstand.

[A]

You know, you know about imposter verifiers and the legitimacy of claimants and authentication binding.

[B]

Yeah, Every poll of that.

[A]

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 got a lot of work to do apparently, and it ain't so basic. So we'll see you next week.

[B]

See you next week, folks. It.