Kveldo requires two-factor authentication on every account with a password — staff and client alike — and there is no way to turn it off. Not an administrator setting, not a support request. The page that used to disable it was deleted from the application.
This is a genuinely unpopular decision in demos, so it is worth setting out the reasoning rather than asserting it.
Optional MFA protects the wrong people
When MFA is optional, the people who enable it are the people already thinking about security. They have strong unique passwords, they use a password manager, and they were not the vulnerable accounts. The accounts that most need a second factor belong to people who will not opt in, because opting in requires already believing you are a target.
So optional MFA produces a distribution almost exactly inverse to need. It also produces a comfortable metric — "MFA is available" — that lets everyone stop thinking about it while the actual exposure is unchanged.
The threat is not sophisticated
Firms tend to imagine a targeted attacker. The realistic scenario is duller and far more common: a staff member reused a password on a site that was breached three years ago, that credential pair is in a combo list, and someone is spraying it at practice management logins because tax firms are a known high-value category.
Nobody targeted your firm. Nobody knows who you are. A second factor defeats the entire attack anyway, because the attacker has a password and nothing else.
What is actually behind the login
Full Social Security Numbers for filers and dependents, FEINs, driver's license numbers, bank account details, complete financial statements, and prior-year returns — for every client of the firm at once. It is difficult to construct a more concentrated identity-theft target, which is why the credential-stuffing traffic exists in the first place.
Why we deleted the page instead of hiding the button
This is the part that is genuinely engineering rather than policy, and it generalizes past 2FA.
The obvious way to remove a capability is to hide its button. The problem is that hiding a button changes what is rendered, not what is reachable — the HTTP endpoint behind it still exists, still accepts a request, and still does what it did. Anyone who can construct that request, or who finds the URL in a cached page or a browser history, can still disable the control.
A hidden button is a user interface decision presented as a security control, and the two are not the same thing. So the route was removed. It now returns 404 for every role, including Super Administrator — which is the important part, because a control that a sufficiently privileged account can switch off is a control that a sufficiently compromised account can switch off.
Why not SMS
Because SIM-swap attacks are cheap and well-documented, and an SMS code is delivered to a phone number rather than to a device — a number that can be ported away from its owner with a convincing phone call to a carrier.
Authenticator apps generate codes locally from a shared secret. There is no message to intercept and no carrier to social-engineer. TOTP is a twenty-year-old open standard, works offline, and every major authenticator app implements it.
SMS is better than nothing, and if it were the only thing standing between a firm and no second factor we would ship it. But we would rather build the recovery path properly than compensate for a weaker factor.
The three friction points, and what removes them
Mandatory 2FA introduces friction in three places. Each one has a fix, and Kveldo ships all three.
- Onboarding friction. Every new user installs an app and scans a code. It is a few minutes, but it is a few minutes at the exact moment they are deciding whether this software is going to be annoying.
- Lost devices. A person replaces their phone without moving their authenticator. This happens regularly and it produces a support interaction every time.
- Client-side resistance. Some clients genuinely find it hard. This is the sharpest cost, because the person absorbing the complaint is your staff, not us.
What we do about each:
- A guided three-step setup with a large QR code and a copyable setup key beside it, because a meaningful share of users are reading the invitation on the phone that is supposed to do the scanning.
- Recovery codes issued at enrollment and regenerable at any time.
- A reset-authenticator path that clears the enrollment flag so a new device can be enrolled — it never leaves the account unprotected, it just re-opens the door to enrolling.
- "Remember this device" for 30 days per browser, so the code is not a daily tax.
Why clients too, and why before launch
A client-portal account holds that client's own tax documents and SSN. That is worth protecting on its own terms, regardless of the fact that it is a smaller blast radius than a staff account.
The timing was deliberate. Mandatory client 2FA went in before the portal opened to end clients, specifically so that no existing client would ever be forced through a re-enrollment event later. Introducing a mandatory security control to people already using a system is a genuinely painful exercise — the only comfortable time to do it is before anyone is there.
The one exemption, and where it does not apply
There is exactly one: a positive match on the Testing environment, or Development with an explicit opt-in setting, so automated tests can run. Production has no such setting — not disabled by default, not present. The code path does not exist there.
We mention this because "we have an exemption for testing" is the kind of sentence that should come with its boundaries stated, and a vendor who cannot tell you precisely where theirs applies is worth another question.
See Kveldo's full security posture →
Read next: the FTC Safeguards Rule and your WISP →