Article
Overview
A practical look at how legitimate email infrastructure can be abused, why it slips past normal expectations, and what SMEs can do to reduce backscatter and inbox noise.
Think about what a hosting account actually controls. Your website. Your domain — which means your email. Your DNS — which means where all of it points. Someone who takes over your hosting account doesn't just deface a page; they can read your mail, reset your other passwords with it, and redirect your customers anywhere they like.
And most hosting accounts are protected by a password someone chose in a hurry in 2019 and reused from somewhere else.
Training people not to click doesn't work
The security industry spent two decades telling people to check URLs carefully before typing their password. It failed. Not because people are stupid — because the attack got better. A modern phishing page is pixel-identical to the real login, sits on a domain that differs by one character, and often proxies your credentials to the real site in real time, capturing the one-time code from your authenticator app along the way. Yes: classic six-digit 2FA falls to a competent real-time phish. The code you type is just another thing to relay.
The only durable fix is a credential that can't be typed at all.
What a passkey actually does differently
A passkey (the same technology as a YubiKey, built into your phone or laptop) is a cryptographic key pair. What makes it different is that the browser, not the human, decides whether the site asking for it is the right one. The credential is bound to the exact domain it was created for. Present a login page on rnanage.veldhost.eu instead of manage.veldhost.eu and the key simply doesn't exist as far as the browser is concerned. There's no code to relay, no password to capture, nothing for the fake page to receive.
The human doesn't have to be careful. That's the whole point. Vigilance is not a security control; domain binding is.
How we use them
Our control panel supports passkeys and hardware security keys as a first-class login method — not buried three menus deep under "advanced security", but as the way in. Authenticator-app codes and recovery codes exist as backup factors underneath.
For administrative access to the platform itself, we went further: there is no password-only path. An admin account cannot reach the control plane until a hardware key is registered, full stop. We enforce on ourselves what we recommend to customers, partly on principle and partly because a hosting provider's admin login is exactly the credential a serious attacker would spend real money phishing.
If you lose your key, recovery is deliberately manual: you email our security address from the account's address, and a human verifies who you are against the details we hold. Slower than a "forgot password" link? Yes. That's the feature. Automated recovery flows are the soft underbelly of every strong-auth system: attackers don't break the vault, they call the front desk.
The honest trade-offs
Passkeys aren't magic everywhere yet. Syncing across ecosystems is still uneven; an iPhone passkey and a Windows desktop don't always cooperate gracefully. You should register more than one credential so a lost phone isn't a lockout. Shared team access needs actual per-person accounts rather than a password in a spreadsheet (our sites support inviting team members with their own logins, which is the correct fix anyway).
And no, we haven't eliminated passwords entirely — a password plus a strong second factor is still the fallback path for customers, because forcing hardware keys on a bakery owner setting up her first website would be preaching over serving. But the door is there, it's the best one on the market, and it's open by default.
If you have two minutes today, spend them adding a passkey to whichever account would hurt most to lose. For our customers that's the Security page in the dashboard. For everyone else — your email account, probably. Everything resets through it.