Security Inequality Gap [Enterprise vs SMB]
How the SSO Tax Turned Small Businesses into Hacker Bait.
It’s fairly well documented that enterprise organizations have widely adopted MFA. This is a good thing, even if we put aside for a moment the fact that no two MFA solutions are alike. For example, some MFA solutions are inherently less secure than others. Another positive trend is that the enterprise is adopting passkeys at a higher rate. This is no surprise, as most enterprise-level organizations have the staff and support to roll out passkeys effectively. A FIDO Alliance study found that 87% of organizations have either deployed or are currently deploying passkeys—a 14% jump from just two years ago.
Enterprises are moving to passkeys to become phishing resistant, while small businesses—the backbone of the economy—are being left behind with SMS-based MFA that attackers can easily bypass. This creates a “soft target” environment where hackers ignore the “fortress” (Enterprise) and feast on the “unprotected” (SMBs).
Within the SMB world, adoption of even simple MFA drops off a cliff. Only 27–34% of small businesses enforce MFA at all, and less than 5% of SMB-facing internal tools offer passkeys as an option.
There are several reasons for this. For one, SMBs typically don’t have staff who understand or can handle the task of being an Identity and Access Management (IAM) administrator. Identity can be complex, requiring knowledge of OIDC, SAML2, SCIM, and more. Many small organizations don’t bother with IAM—and thus passkeys—because they simply don’t have the technical expertise.
One of the biggest challenges, and where I think many SaaS providers fail their customers, is the “SSO tax.” Even if a small organization decides to implement IAM, many tools will charge an extra “fee” simply for the right to use an SSO provider. I’ve heard many excuses for this. For example: “As a SaaS provider, we now have to keep up with the codebase for OIDC or SAML2.”
This strikes me as ridiculous. That statement implies that once an OIDC or SAML2 connector is built into a SaaS service, there is a massive, ongoing development effort required to maintain it. This is simply not true. I would argue that “rolling your own” auth is not only more complex but also creates more risk for the SaaS provider.
The bottom line is that SaaS providers know “enterprise” clients have deep pockets and will pay enterprise rates. What they really mean is that because authentication methods like OIDC and SAML2 are considered “enterprise-level,” they feel justified in charging enterprise-level rates. Translation: the enterprise will pay more, so we charge more. There is no other reason.
To get around the “SSO tax,” some smaller identity players have decided to bypass it using automatic “form filling.” In this scenario, a legacy username and password form is presented to the user, and the credentials are automatically entered for them.
In most cases, this breaks the “Zero Trust” cycle. Many Identity Providers simply store the username and password within a database on their backend. This means that if they are compromised, those credentials could be exposed. Compare that to public key cryptography: even if a public key is exposed, there is no harm done.
A provider may tell you that they store usernames and passwords within “encrypted vaults.” That might be true, but encrypted or not, centralizing all credentials into one online “safe” creates a single, catastrophic point of failure. The LastPass hack, for example, led to millions of customer vaults being stolen. Attackers then searched the vaults for high-value targets by examining the URLs stored within. How did they get access to the URLs if the vaults were encrypted? While the usernames and passwords were encrypted, the URLs were not. Hosting millions of “vaults” made LastPass a massive target.
It is possible to create “encrypted local vault” systems that allow for automatic form filling and interact with your IdP, but these get complex and can still lead to other issues—such as the KeePass “memory dump” vulnerability (CVE-2023-32784).
On top of all this, with these systems, you are still using passwords!
Which leads us right back to public key cryptography (i.e., passkeys and SSH keys). While no system is 100% perfect, public key cryptography mitigates many of these vulnerabilities.
This is what Key9 is 100% built on. We’re trying to not only make the user experience seamless but create a true Zero Trust solution.
As I’ve seen in my decades-long experience in computer and network security, while we would like the road to lead toward more secure solutions, laziness and greed often keep us from getting there.
We hope that Key9 can be a small stepping stone in changing that.