Why Passwords Are Failing SMEs: The Growing Risk of Phishing Attacks
Your accounts payable clerk gets an email that looks exactly like it came from your bank. She clicks, types her username and password into a page that looks exactly like the real login screen, and thirty seconds later a criminal in another country has her session. No malware. No exploit. Just a password, handed over willingly to something that looked real enough.
This is not a hypothetical. Verizon's annual Data Breach Investigations Report has listed stolen or misused credentials among the top entry points into corporate networks for over a decade running, and phishing remains one of the cheapest, most scalable ways to get them. Large enterprises absorb this risk with dedicated security operations teams, forced password rotation, and SIEM tooling watching for anomalous logins at 3am. A 40-person logistics broker in Chonburi has none of that. It has an IT contractor who visits twice a month and an owner who thinks two-factor authentication is "the code thing on my phone."
SMEs are not targeted less than large enterprises — they're targeted more, because the payoff-to-effort ratio is better. A password reused across a Gmail account, a bank portal, and your Odoo instance is a single point of failure that costs the attacker nothing to exploit and costs you the business relationship you spent five years building. The uncomfortable truth: most SME security postures still rest entirely on the assumption that employees will always be able to tell a fake login page from a real one. They can't. Neither can you, half the time.
How Passkeys Work: The Technology Behind Phishing-Resistant Sign-In
A passkey is not a stronger password. It's a different category of credential entirely, and the distinction matters.
When you register a passkey, your device generates a public/private key pair. The private key never leaves your device — not your phone, not your laptop's secure enclave, not your Yubikey. The public key goes to the service you're logging into (Odoo, your bank, Microsoft 365). When you sign in, the service sends a challenge, your device signs it with the private key, and the service verifies it with the public key it already has. Nothing secret is ever transmitted. There is no password for a phishing site to capture, because there is no password.
The phishing-resistance comes from a detail most people miss: the cryptographic signature is bound to the origin — the exact domain — that requested it. If a fake site impersonates your bank at "yourbank-secure-login.com," a passkey registered against the real bank's domain simply will not sign a challenge from the fake one. The browser won't even offer it as an option. This is the mechanism defined in the WebAuthn specification maintained by the W3C ([W3C WebAuthn Level 3](https://www.w3.org/TR/webauthn-3/)), and it's why passkeys can't be phished the way a password or an SMS code can — the attack surface that phishing relies on simply doesn't exist in the protocol.
For anyone running Odoo, this matters directly. Odoo 18, released October 2024, added native passkey and WebAuthn support, including in the free Community edition. If you're still on Odoo 17 or earlier, you're limited to password plus optional TOTP-based two-factor authentication — no native passkey login. That's a real reason to plan an upgrade, not just a versioning footnote (see the [Odoo 18.0 release notes](https://www.odoo.com/odoo-18-release-notes)).
Passkeys vs. Traditional MFA: Why Passkeys Offer Better Security Without Extra Friction
Most SMEs that have bothered with MFA at all are running SMS codes or a TOTP app like Google Authenticator. Better than nothing. Not as good as people assume.
SMS OTP can be intercepted through SIM-swap fraud, and it's been formally discouraged as a primary authenticator by NIST for years (see [NIST SP 800-63B, Digital Identity Guidelines: Authentication and Lifecycle Management](https://pages.nist.gov/800-63-3/sp800-63b.html)). TOTP codes are more resilient but still phishable — a well-built adversary-in-the-middle relay page will happily prompt the victim for their six-digit code in real time, forward it to the real site within the 30-second window, and steal the resulting session cookie. The victim did everything "right" and still got compromised. Adversary-in-the-middle relay kits like this are increasingly common in commodity phishing-as-a-service offerings, not just nation-state tooling.
Passkeys close that gap because there's no code to relay and no secret to type into anything. Compare the actual user experience:
- TOTP: type password, unlock phone, open app, read six digits, type six digits before they expire, hope you didn't fat-finger it.
- Passkey: touch fingerprint sensor or glance at phone. Done.
Less friction, not more, and a materially harder target. This is also why NIST and the U.S. federal government's zero-trust mandate explicitly separate "phishing-resistant authentication" as its own tier above ordinary MFA (see [OMB Memorandum M-22-09, Moving the U.S. Government Toward Zero Trust Cybersecurity Principles](https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-09.pdf)). Passwords plus TOTP satisfy "MFA." They do not satisfy "phishing-resistant." Passkeys do.
Getting Started with Passkeys: Adoption Steps for SME Teams
You don't need a security team to start. You need a plan that doesn't fall over the first time someone loses their phone.
- Inventory what supports passkeys today. Odoo 18+, Google Workspace, Microsoft 365, GitHub, most major password managers (1Password, Bitwarden) all support them now. Anything running Odoo 17 or older won't offer native passkey login — factor that into your upgrade roadmap rather than treating it as a separate project.
- Pick a pilot group of five to ten people, ideally including at least one person who is not technical. If it works for your least tech-comfortable employee, it'll work for everyone.
- Register passkeys on personal devices first — phone or laptop biometric unlock — before touching shared or warehouse-floor terminals, which need a different approach (more on that below).
- Set up recovery paths before you need them. Every passkey rollout needs a documented process for lost or stolen devices: backup codes generated at enrollment, or a second registered device, stored somewhere that isn't "in the same bag as the laptop."
- Keep passwords disabled as a fallback only where compliance genuinely requires it, not because IT is nervous about the change. Every password fallback path you leave open is a door you didn't actually close.
- Train on the failure mode, not just the happy path. Show staff what a passkey prompt looks like on a fake site (nothing happens) versus the real one (it just works). That contrast is the whole point.
Budget for this in weeks, not months, for a business under 50 users. The technology isn't the hard part. Getting five people to actually register their passkey before Friday is.
Real-World Challenges: Rollout, Legacy Systems, and User Adoption
None of this is friction-free, and pretending otherwise would undercut everything above.
**Shared devices are the real obstacle.** A passkey is tied to a device or an account-bound password manager, which is fine for office staff with their own laptop. It's a genuine problem for a warehouse floor where three shifts share two barcode-scanning terminals logged into Odoo Inventory. Passkeys work best per-person, and per-person authentication on shared hardware means either cross-device passkey sync (via a passkey-enabled password manager or platform account) or accepting that some shared-terminal logins stay password-based with tighter compensating controls. There's no clean answer here, only a trade-off you pick deliberately instead of by default.
**Passkeys move the trust problem, they don't remove it.** Cross-device sync usually runs through your platform vendor — iCloud Keychain, Google Password Manager, or a third-party vault like 1Password. That's what makes passkeys practical across a phone and a laptop instead of locked to one device, and it also means Apple's or Google's account-recovery security is now effectively your authentication system's weakest link. A compromised Apple ID or a social-engineered Google account recovery can hand over every synced passkey at once. That's not a reason to skip passkeys — password reuse across services is a worse version of the same single-point-of-failure problem — but it's a real cost of the technology itself, not just rollout friction, and it belongs in whatever security policy you write.
**Legacy systems won't move at your pace.** Your accounting add-on from 2016, your industry-specific EDI portal, your bank's business banking site — some of these will not support WebAuthn for years, if ever. A phased rollout that starts with your Odoo instance, your email, and your password manager, leaving the legacy holdouts on strong unique passwords plus TOTP, is realistic. A rollout that promises "no more passwords anywhere by Q2" is not.
**Device loss recovery is where trust breaks.** If someone loses the phone holding their only passkey and there's no backup registered, they're locked out — and a badly designed recovery process becomes its own social-engineering target, because now your help desk is the weak link instead of the login page. Run that drill before an actual incident forces you to improvise one.
**Offboarding needs a checklist update.** When someone leaves, deprovisioning now means revoking their passkeys from every registered system, not just disabling a password. HR and IT need a shared list of where passkeys were enrolled, updated as each new service gets added — a small process fix, but the kind that's easy to skip until an ex-employee's old laptop still opens something it shouldn't.
Passkeys and Compliance: Meeting Security Standards as an SME
Compliance pressure on this is rising faster than most SME owners realize. Cyber insurance renewal questionnaires increasingly ask specifically what type of MFA you use, and "SMS-based" or "app-based TOTP" is starting to draw follow-up questions or premium loading, while phishing-resistant methods do not. ISO 27001 control frameworks around access management don't mandate passkeys by name, but auditors assessing your authentication controls will ask what protects against credential phishing specifically — and "we have MFA" is a weaker answer than it was three years ago.
Government and enterprise procurement is moving the same direction. The U.S. federal zero-trust mandate cited earlier treats phishing-resistant authentication as the baseline standard for sensitive systems, not an aspirational goal (M-22-09, again). If you sell into government supply chains or handle data under frameworks that reference NIST guidance, this bar is coming for your contracts whether or not it's arrived yet.
None of this means ripping out every password tomorrow. It means treating passkeys as the default for anything touching financial systems, customer data, or your ERP — Odoo included, provided you're on 18 or later — and treating every remaining password-only login as a known, documented exception rather than an oversight nobody noticed.