Passkeys vs. Passwords for Business: Are Passkeys Ready for SMBs?

A CMMC assessor sitting across the table from a 40-person machine shop doesn’t care whether the shop’s password policy looks good on paper. They care whether the identification and authentication controls actually hold up against a credential-stuffing attempt, a phished login page, or an employee who reused their Office 365 password on a hobby forum that got breached eighteen months ago. That’s the reality small and mid-sized defense contractors are living in right now, and it’s why the question of passkeys versus passwords has moved from a curiosity in security blogs to a real decision on IT roadmaps for machine shops, engineering firms, and prime subcontractors in Boston, Tampa, and Sarasota.

The stakes are different for a defense subcontractor than they are for a retail chain worrying about loyalty-account takeover. A stolen credential at a company handling CUI isn’t just a nuisance ticket for the help desk — it’s a potential DFARS incident-reporting event, a possible SPRS score revision, and in the worst cases, the kind of finding that stalls a CMMC assessment for months while the organization rebuilds trust with an assessor. We’ve sat in enough post-incident debriefs to know that the conversation almost always circles back to the same question: could this have been prevented at the login screen? Increasingly, the answer is yes, and the technology that makes that possible has finally matured enough for an SMB to deploy it without a six-figure identity project.

The Credential Problem Defense Contractors Can’t Ignore Anymore

Every incident response engagement we’ve run over the past two years traces back to the same root cause more often than any other: a compromised credential. Not a zero-day. Not a misconfigured firewall. A password that was phished, guessed, reused, or sold on a dark web marketplace after an unrelated breach. For a defense contractor storing Controlled Unclassified Information, that’s not a theoretical risk — it’s the exact scenario DFARS 252.204-7012 was written to prevent, and it’s the scenario a compromised assessment finds when a company can show MFA on paper but can’t show it actually stopped anything.

The uncomfortable truth is that most password-based MFA still leaves a gap. One-time codes sent by SMS or generated by an authenticator app protect against a stolen password used in isolation, but they don’t protect against a real-time phishing proxy that relays the code the instant a user types it into a fake login page. That’s precisely the attack pattern CISA has flagged repeatedly in its guidance to critical infrastructure and defense industrial base organizations, and it’s the gap passkeys were built to close.

What a Passkey Actually Is (And Why It’s Not Just “MFA With Extra Steps”)

A passkey isn’t a stronger password. It’s a cryptographic key pair generated on the device — a laptop, phone, or hardware security key — where the private key never leaves that device and the public key sits on the server. When a user logs in, the server sends a challenge, the device signs it locally (usually after a fingerprint, face scan, or PIN unlocks the key), and the signed response goes back. Nothing that could be phished, guessed, or reused ever crosses the network. There’s no shared secret to steal because there’s no shared secret at all.

This is why passkeys are categorized as phishing-resistant authentication, a distinction that matters a great deal once you’re mapping controls against NIST SP 800-171 identification and authentication requirements. A password plus a push notification can still be defeated by a sufficiently motivated attacker running an adversary-in-the-middle proxy. A passkey tied to a specific device and a specific origin domain cannot be relayed to a fake site, because the cryptographic handshake is bound to the real one.

There are two flavors worth distinguishing, because they carry different implications for a compliance-driven environment. Device-bound passkeys live exclusively on a single piece of hardware — a YubiKey, a laptop’s TPM chip, a phone’s secure enclave — and never leave it, which is the stronger posture for anyone handling CUI directly. Synced passkeys, by contrast, replicate across a user’s devices through a cloud keychain, trading a bit of that isolation for the convenience of not being locked out when a single device is lost. For most day-to-day business accounts synced passkeys are a meaningful upgrade over passwords regardless. For privileged accounts touching CUI, device-bound is the standard worth insisting on, and it’s the distinction your written policy needs to make explicit rather than leaving to individual employee preference.

Passwords Were Never Supposed to Survive This Long

The password was designed in an era when the biggest threat was a coworker peeking at a sticky note, not an automated botnet running billions of credential-stuffing attempts against a login page in a single afternoon. Every mitigation layered on top since then — complexity rules, rotation policies, password managers, MFA — has been a patch on an authentication model that was never built to withstand the current threat landscape.

The irony compliance teams run into constantly is that stricter password policies often make security worse in practice. Force a 16-character rotation every 60 days and employees write it on a sticky note, store it in a spreadsheet, or pick a pattern predictable enough to guess from the last three passwords. We’ve walked into engineering firms with sophisticated technical controls everywhere except the one place attackers actually go first: the login screen. If your organization’s cybersecurity posture still leans on password complexity as its primary identity control, passkeys represent the first authentication upgrade in a decade that doesn’t ask users to remember something — it asks them to simply be who they already proved they were when they unlocked their device.

Where Passkeys Meet CMMC Level 2 Identification and Authentication Requirements

CMMC Level 2 maps directly to the 110 controls in NIST SP 800-171, and the identification and authentication family (IA) is where passkeys have the clearest, most defensible fit. Controls requiring multifactor authentication for network access, for privileged accounts, and for remote access are all satisfied — arguably exceeded — by a properly deployed passkey, because the “something you have” and “something you are” factors are baked into the same cryptographic ceremony rather than bolted on as a separate step.

Where it gets more nuanced is documentation. An assessor reviewing your System Security Plan wants to see how passkey enrollment, device binding, and recovery are governed, not just that the technology exists. Organizations preparing for their next assessment often discover this gap the hard way, which is one reason we wrote a companion piece on what CMMC compliance actually requires beyond the checklist — the technology decision is only half the work; the governance around it is what an assessor is actually scoring. Organizations building or refreshing their compliance documentation should treat passkey rollout as a control change that needs its own policy language, not a silent IT upgrade.

Your SSP narrative also needs to address the identity provider itself. Whether authentication runs through Entra ID, Okta, or a similar platform, the assessor wants a description of how the passkey ceremony ties back into your access control policy — how enrollment is verified, who approves a new device registration, and what happens when an employee leaves the organization and their bound credentials need to be revoked immediately rather than sitting dormant on a decommissioned laptop. None of this is difficult to document once the process exists, but a lot of SMBs deploy the technology first and write the policy language as an afterthought, which is exactly the order that produces an assessment finding.

The Practical Gaps: Where Passkeys Still Struggle in an SMB Environment

None of this means passkeys are a drop-in replacement for every login on day one. There are real friction points an SMB needs to plan around before declaring passwords dead:

• Legacy line-of-business applications. A lot of manufacturing ERP systems, older accounting platforms, and industry-specific CAD or PLM tools simply don’t support FIDO2/WebAuthn yet, and won’t for years. Passwords aren’t going anywhere in those environments.
• Cross-device and cross-platform sync. Passkeys synced through Apple’s iCloud Keychain or Google Password Manager work beautifully within one ecosystem and awkwardly across a mixed Windows/Mac/mobile fleet, which describes most engineering and manufacturing shops.
• Shared workstations. Shop floor terminals, kiosk-style machines, and shared engineering workstations complicate device-bound passkeys, since the model assumes one primary user per device.
• Account recovery. If an employee loses their phone or laptop, the recovery process needs to be as rigorous as the original enrollment, or you’ve just created a new social-engineering target at the help desk.
• Vendor and partner access. Contractors granting portal access to subcontractors or auditors don’t control those third parties’ hardware, so passkey enforcement can’t always be a hard requirement outside your own environment.

None of these are reasons to wait indefinitely. They’re reasons to sequence the rollout by application and user group rather than flipping a single switch. Most of the SMBs we’ve guided through this transition find that roughly 60 to 70 percent of daily logins — email, cloud file storage, project management tools, the core ERP if it’s a modern SaaS platform — support passkeys today, while the remaining fraction sits in legacy systems that simply need a longer runway and a compensating control in the meantime.

Passkeys and Phishing-Resistant MFA: Closing the Gap Nation-State Actors Exploit

The defense industrial base isn’t dealing with opportunistic criminals looking for an easy payday. It’s a named target for state-sponsored actors specifically because of what flows through the supply chain — technical drawings, program schedules, and CUI that has intelligence value well beyond whatever a ransomware operator could extract. CISA’s advisories on nation-state cyber activity have repeatedly called out credential theft and phishing as the primary initial access vector against exactly this sector, which is why the phishing-resistance built into passkeys carries more weight for a defense subcontractor than it would for a typical retail business.

NIST SP 800-172 — the enhanced security requirements layered on top of 800-171 for information of particularly high value — pushes further into this territory, emphasizing controls designed to resist advanced persistent threats rather than commodity attacks. Passkeys align naturally with that intent even where they aren’t explicitly named, because the entire threat model 800-172 is written against assumes an adversary capable of running a convincing phishing campaign. A control that removes the phishable credential from the equation entirely does more real-world work than another layer of user training ever will.

Security awareness training still matters, but it’s worth being honest about its ceiling. Even well-trained employees click the wrong link under enough time pressure or a convincing enough pretext, and a single click against a password-based login is often all it takes. Passkeys change the economics of that mistake: an employee can click a phishing link, land on a convincing fake page, and the authentication simply fails, because the fake domain can’t produce a valid challenge the passkey will sign. That shift — from relying on human judgment in the moment to relying on cryptography that doesn’t care how convincing the email looked — is the single biggest reason this technology deserves serious consideration ahead of the next assessment cycle rather than the one after that.

What a Realistic Rollout Looks Like for a 20-to-150-Person Contractor

We don’t recommend an all-at-once cutover for any client, regardless of size. A phased approach protects productivity while still moving the needle on real risk:

1. Start with privileged and administrative accounts — domain admins, financial system approvers, anyone with elevated access to CUI environments — since these carry the highest blast radius if compromised.
2. Move to Microsoft 365 and core cloud identity next, since Entra ID and most major identity providers now support passkeys natively and the user experience is close to seamless.
3. Layer in VPN and remote access authentication, particularly relevant for hybrid teams working across Boston, Tampa, and Sarasota offices where remote connections into CUI environments need the strongest available control.
4. Address legacy and line-of-business applications last, on whatever timeline the vendor’s own roadmap allows, keeping strong password-plus-MFA as the interim control.

This sequencing keeps a rollout achievable for a lean internal IT team, and it’s the same order we walk clients through under both fully managed IT services and co-managed IT arrangements, where an internal admin handles day-to-day tickets and we handle the identity architecture underneath it.

Timeline expectations matter here too. A privileged-account rollout across a 50-person contractor typically takes two to three weeks once hardware keys or device enrollment policies are in place — most of that time is enrollment logistics, not technical complexity. The cloud identity phase for the broader workforce usually runs another four to six weeks when you account for a staggered rollout by department, a help desk that can absorb the enrollment questions without falling behind on other tickets, and a short overlap period where both passkey and password-plus-MFA remain available while adoption climbs toward full coverage.

Passwords Won’t Disappear Overnight — Here’s the Hybrid Model That Works

The honest answer to “are passkeys ready for SMBs” is that they’re ready for the accounts that matter most, and not yet ready to be the only authentication method in the building. A defensible hybrid model treats passkeys as the primary credential wherever the platform supports it, keeps strong, unique passwords generated and stored in a managed password vault everywhere else, and eliminates shared or static passwords entirely from any account touching CUI. This mirrors the layered approach we recommend for backup and data recovery planning — you don’t rely on a single control to carry the entire risk; you build redundancy into the identity layer the same way you build it into your data protection strategy.

Manufacturing shops running older MES or ERP platforms and engineering firms tied to specific CAD licensing servers are the clearest examples of environments where this hybrid model isn’t optional — it’s the only realistic path for the next several years. Businesses in our manufacturing and engineering client base tend to have the widest gap between what their newest cloud systems support and what their oldest shop-floor systems will tolerate, which is exactly why a phased, application-by-application plan matters more than a company-wide mandate.

Where a password vault stays in the picture, it needs to be a managed one — a shared spreadsheet or a browser’s built-in password storage doesn’t meet the intent of any identification and authentication control an assessor will accept, and it creates exactly the kind of single point of failure passkeys are meant to eliminate elsewhere in the environment. Every password that remains in use should be unique, machine-generated, and rotated on compromise rather than on an arbitrary calendar, since forced rotation on a schedule is precisely the practice that drives employees toward predictable patterns in the first place.

Cost, Support Burden, and the vCIO’s Role in Getting This Right

Passkey deployment isn’t expensive in licensing terms — most organizations already own the identity platform capability through their existing Microsoft or Google tenant. The real cost is planning time: mapping which applications support FIDO2 today, deciding on a device-bound versus synced-passkey policy, writing recovery procedures that don’t undermine the security gain, and training help desk staff to verify identity through a process that can’t be socially engineered the way a password reset call can.

This is squarely the kind of cross-functional decision that belongs with a vCIO rather than being left to whichever admin has the most free time that quarter. We’ve written before about what a vCIO actually does and whether a business needs one, and identity architecture is a textbook example — the decision touches budget, compliance documentation, user experience, and long-term vendor roadmaps all at once. Contractors weighing whether to bring this expertise in-house or lean on an outside partner should also look at our breakdown of co-managed IT versus fully outsourced IT, since the right identity strategy often depends on how much internal bandwidth already exists to own it day to day.

Support ticket volume typically drops after a passkey rollout stabilizes, since “I forgot my password” disappears as a category almost entirely. The trade-off is a heavier lift during enrollment, particularly for less technical staff who need hands-on help registering a security key or setting up biometric unlock on a company laptop for the first time. Budgeting a few weeks of elevated help desk support during rollout is realistic; budgeting for it indefinitely is not, because the entire point of the technology is that it reduces friction once it’s in place.

Hardware security keys deserve a specific budget line rather than being treated as an afterthought. A YubiKey or equivalent FIDO2 key runs somewhere in the $25 to $60 range per employee depending on the model, and shared or public-facing workstations may need a small pool of spares for employees who forget theirs at home. Compare that per-seat cost against the average incident response engagement following a credential-based breach, and the math tends to justify itself within the first prevented incident. The harder cost to quantify — but the one that matters most in a CMMC context — is the difference between an assessor finding a mature, documented identity control and finding a password policy that technically satisfies the letter of a requirement without addressing the threat it was written for.

Conclusion

Passkeys aren’t a future technology defense contractors should wait to adopt — they’re a present-day control that closes the exact phishing and credential-theft gap driving the majority of breaches against the defense industrial base, and they align cleanly with the identification and authentication requirements built into NIST SP 800-171 and reinforced under the DoD CMMC Program. The realistic path for most SMBs isn’t a full replacement of passwords on day one — it’s a phased rollout starting with privileged accounts and cloud identity, backed by CISA guidance on phishing-resistant MFA and informed by the enhanced security requirements in NIST SP 800-172 for organizations handling higher-value CUI. Given how consistently CISA has documented nation-state actors targeting credentials across the defense supply chain, this isn’t a decision that benefits from waiting for a more convenient budget cycle.

If your organization is planning its CMMC compliance journey, contact Stealth Technology Group today at (617) 903-5559 or visit the website to learn how modern cybersecurity infrastructure can accelerate your path toward certification readiness.