The Real Cost of Weak Passwords for Small Businesses
Attackers don't skip small businesses, they automate straight through them. Here's the real bill for a credential-stuffing breach, why "we're too small to matter" is the most expensive thing a founder can believe, and how going passwordless removes the target instead of hardening it.
The first time someone broke into a customer's account on a product I'd shipped, I found out from a one-star review. Not an alert, not a log, not a dashboard pulsing red like in the movies. A review. "Someone changed my email and ordered a TV to an address in another city, thanks for nothing." I refunded it, apologised, and then spent the rest of the night staring at our access logs realising the attacker hadn't done anything clever. They hadn't found a bug. They'd just tried a few thousand email-and-password pairs they'd bought somewhere for less than a sandwich, and one of them worked, because that customer used the same password here that they'd used on a forum that got breached in 2019. The whole intrusion cost the attacker roughly the price of a coffee and zero skill. The cleanup cost me a weekend and the customer cost me forever.
I run a passwordless identity company now, so you can guess where this is going, but I want to earn it rather than just assert it. Because the thing I really learned that night wasn't "passwords bad." It was that small businesses carry the exact same attack surface as the giants, with none of the security team, none of the budget, and a comforting little lie whispering in our ear that nobody would bother coming for us. They bother. They bother precisely because we believe they won't.
You are not too small. You are the easy one.
There's a fantasy a lot of founders quietly hold, and I held it too: that we're beneath the notice of attackers, that the real targets are banks and Fortune 500s and people with something worth stealing. This is backwards. Attackers are not artisans hand-picking glamorous victims. They are running automation that doesn't know your revenue and doesn't care. Credential stuffing is the dominant flavour: someone takes a giant list of leaked email-and-password combos from old breaches, points a bot at thousands of login pages, and just tries them everywhere. The bot doesn't read your About page and decide you're too humble to rob. It tries the door. If the door opens, it walks in. Your smallness isn't camouflage. It's the reason you don't have the rate-limiting, the anomaly detection, and the dedicated humans that would slow the bot down at a bigger company.
And the economics are brutally lopsided. The attacker's cost is near zero, fully automated, fully reusable. Your cost when they succeed is very much not zero. People reuse passwords, that's just the world we live in, so a leak from some unrelated website three years ago becomes a working key to your customer's account on your service today. You did nothing wrong and you're still on the hook, because the trust relationship that breaks is the one between your customer and you, not your customer and the forum that actually leaked. Try explaining that nuance to someone whose order history just got drained. I have. They do not care about the nuance, and honestly, they're right not to.
The bill nobody itemises until it lands
When people talk about the cost of a breach they reach for the scary headline number, the average-cost-of-a-data-breach stat that's mostly built from enterprises and doesn't map to a six-person company. So let me itemise the version that actually shows up in a small business's bank account and calendar, because that's the bill I've paid. First, downtime. While you're scrambling to figure out what happened, lock things down, and rotate credentials, you're not selling, you're not building, and you're paying everyone to firefight instead of work. A day of that for a small team is real money that simply evaporates.
Then come the support tickets, and this is the cost people wildly underestimate. One account takeover doesn't generate one ticket. It generates the takeover ticket, then the "is my account safe too" tickets from everyone who heard about it, then the password-reset flood when you force a rotation, then the angry follow-ups when the reset email lands in spam. A single incident can bury a small support function for a week, and if support is just you and a shared inbox, that week is your week. Behind that sits reset fatigue, the slow tax where every forced password change trains your customers to pick weaker passwords, reuse more, and resent you a little, which quietly makes the next breach easier. You are not fixing the problem. You are amortising it onto your users and calling it security.
After that the costs get less visible and more permanent. There's the regulatory exposure, because depending on where your customers live, a breach involving personal data can drag you into GDPR or state privacy laws with fines and mandatory notifications that assume you have a compliance department, which you do not. There's the chargebacks and fraud losses if money or goods moved. And then there's the one you can't expense: the trust. Customers who get burned don't write you an email explaining their departure. They just stop, tell two friends, and you never know the lifetime value you lost because it never showed up as a line item. A breach at a small company isn't a one-time cost. It's a slow leak in the thing your whole business floats on.
"We'll just enforce stronger passwords" is a trap
The instinct after an incident is to crank the password policy. Longer minimums, special characters, ninety-day rotation, a complexity meter that judges people. I understand the instinct. It feels like doing something. It mostly does nothing for the attack that's actually hitting you. Credential stuffing doesn't guess passwords character by character, so password complexity is irrelevant to it, the attacker already has the plaintext from somewhere else. Forced rotation, which sounds responsible, has been shown to make passwords weaker because humans cope by adding a "1" and then a "2," and even the standards bodies that used to push rotation have quietly walked it back. So you've added friction your customers feel on every login, generated a wave of reset tickets, and reduced your protection against the precise threat you were panicking about. Congratulations, you've made it worse and more annoying at the same time.
Multi-factor helps, genuinely, and you should turn it on, but SMS codes get intercepted and phished through reverse-proxy kits, and even app-based one-time codes can be relayed in real time by a convincing fake login page. MFA raises the bar. It does not remove the thing being attacked, which is the shared secret sitting in your database waiting to match a stolen one. As long as there's a password to steal, reuse, leak, phish, or guess, you're managing a liability, not eliminating it. You're a better-locked house on a street full of houses, and the bot just goes house to house.
Going passwordless doesn't harden the target. It removes it.
Here's the shift that actually changed how I think about this, and it's not "use a better password," it's "stop having one." With passkeys, there is no shared secret stored on your server to be stolen in the first place. Each user has a private key that never leaves their device and a public key you store, and the public key is useless to an attacker, it's public by design, you could print it on a billboard. When someone logs in, their device signs a one-time challenge and you verify the signature. Nothing reusable crosses the wire, nothing sits in your database waiting to match a leaked list, and there's no password reset flow to social-engineer because there's no password. The credential-stuffing bot that cost a coffee to run shows up, finds nothing to stuff, and moves to the next house. You're no longer a better-locked house. You took the lock off the equation entirely.
And because passkeys are cryptographically bound to your actual domain, the phishing page that relays codes in real time simply can't get a signature for the wrong origin, so that whole class of reverse-proxy attack dies too. From a small-business owner's seat, the part that matters is mundane and wonderful: the breach you spend your nights worrying about needs a stolen password to work, and you no longer have stolen passwords to lose. We built Paswad around exactly this idea because I was tired of selling people stronger locks for a door the attackers were walking around. It isn't a magic shield against everything, social engineering and account recovery still need care, but it deletes the single most common, most automated, most boring attack on the internet, and boring is what robs small businesses.
If you run a small business and you take one thing from a guy who learned this from a one-star review: stop measuring your security by how strong your passwords are, and start measuring it by how much you'd lose if every password you store leaked tomorrow. Then go make that number smaller. Turn on passkeys where you can, offer them to your customers, and start treating shared secrets as the liability they are rather than the security feature we all pretended they were. The attackers already updated their tooling. The only question is whether you update yours before or after the review gets posted.
FAQ
Why would attackers bother with a small business?
Because they're not choosing you, they're choosing everyone at once. Credential stuffing is automated: a bot throws millions of leaked email-and-password pairs at thousands of sites with no idea or care how big you are. Small businesses are actually easier targets because they rarely have the rate-limiting, monitoring, and security staff that slow these bots down at larger companies. Your size is an advantage to the attacker, not a shield.
What does a credential-stuffing breach actually cost a small business?
Far more than the stolen item. You pay in downtime while you firefight, a flood of support tickets that one takeover can multiply into dozens, password-reset fatigue that trains customers toward weaker habits, potential regulatory fines and breach-notification duties, chargebacks if money moved, and the quiet, permanent loss of customer trust that never shows up as a line item. For a small team, a single incident can swallow a week and a reputation.
Won't stronger password rules and forced resets fix it?
No, and they often make things worse. Credential stuffing uses passwords already stolen in plaintext from other sites, so complexity rules don't touch it. Forced rotation pushes people toward predictable, weaker passwords, which is why modern guidance has dropped it. You end up adding friction and generating reset tickets while doing little against the actual threat.
How does going passwordless reduce the attack surface?
It removes the thing being attacked. With passkeys there's no shared secret stored on your server, so there's nothing for a stuffing bot to match against a leaked list and nothing to phish or reset. Logins work by signing a one-time challenge with a private key that never leaves the user's device, and because the signature is bound to your real domain, lookalike phishing pages can't use it either. You're not hardening the password, you're deleting it.