Why legacy authentication is the first place modern attacks land
Because it is the cheapest target you own. A password form needs no exploit, no zero day and no insider. An attacker needs a list of email addresses, a list of leaked passwords and patience. Legacy login stacks supply the rest: no rate limiting, no device binding, no anomaly detection, no alert when it works.
Most breach chains that end in encrypted servers or exported customer data begin with a login that simply succeeded. Criminal crews do not burn expensive vulnerabilities when valid credentials exist, and they do not need code execution when an administrator account already grants it.
- ▸No exploit means no patch alert. A successful login is not an intrusion event on an old system, it is a normal Tuesday in a log nobody reads.
- ▸Legacy stacks fail open. Old mail protocols, basic auth on internal tools, SOAP endpoints and forgotten admin panels predate your MFA decision and quietly sit outside it.
- ▸The blast radius is total. Authentication is the control that every other control silently assumes is working.
For the wider picture of what a small estate should have in place, see The Small Business Website Security Checklist for 2026.
What legacy authentication actually means in your stack
It means any path that authenticates a person or a service using only a shared secret, with no proof of device, origin or session integrity. It is rarely just the login page. It is the set of side doors built before the MFA project, still enabled because nobody could prove they were unused.
The typical inventory in a ten year old estate:
- ▸Password-only web logins on the CMS, the ERP, the accounting tool and the staging server nobody switched off.
- ▸Legacy protocols that cannot present an interactive challenge, so they sit outside MFA policy by default rather than by decision.
- ▸API keys and service accounts with no expiry, stored in config files, shared across environments, known to people who left years ago.
- ▸Sessions that never end, remember-me cookies measured in months, and tokens with no revocation path.
- ▸SMS and email one-time codes, better than nothing and far weaker than most owners believe.
Reset flows belong on that list too, because reset was built as a support convenience and never threat modelled. The gap between what your policy says and what your systems actually accept is your real posture.
Credential stuffing works because password reuse is universal
Credential stuffing is not guessing. It is replaying real username and password pairs from historical breach dumps against your login, at scale, from thousands of addresses. It works because people reuse passwords across work and personal accounts, and they always will.
The mechanics are dull and effective. Attackers assemble combination lists and test them against any endpoint that returns a distinguishable success. Traffic arrives through residential proxy pools, so blocking by IP address catches very little, and rates are tuned to stay under whatever threshold the platform enforces, which on legacy systems is usually none at all.
What makes it worse on old systems:
- ▸Verbose failures. A login that says the account does not exist hands over a free enumeration oracle.
- ▸Unprotected secondary paths. The main form may be rate limited while the mobile endpoint, the legacy API and the reset flow are not.
- ▸No credential screening. New passwords are never checked against known compromised sets, so users re-import the exact password that leaked somewhere else.
Staff can check their own exposure through Have I Been Pwned, but the durable fix is screening new and changed passwords against known-compromised sets inside your registration and reset flows automatically, rather than hoping people look.
Infostealers make the password almost irrelevant
Infostealer malware skips authentication entirely. It runs on a laptop, harvests saved browser passwords, cookies and session tokens, and ships them to a marketplace. The buyer loads the cookie into their own browser and arrives inside your application as an already-authenticated user, with the MFA step behind them.
This is the failure mode that surprises owners most. The password policy was fine and MFA was enabled, but the attacker never touched the login page: they replayed a live session your system could not distinguish from the genuine one.
Old systems are unusually generous here:
- ▸Sessions with no absolute expiry stay valid long after the theft.
- ▸No binding to device, address or client fingerprint, so a session used from a new country and a new browser raises nothing.
- ▸No revocation mechanism, so even once you know about the theft you cannot kill one session without a global logout you are afraid to run.
- ▸Tokens in browser storage reachable by any injected script, which is why the injection classes in the OWASP Top 10 matter far more on an authentication surface than anywhere else.
MFA fatigue: why "we have MFA" is not an answer
Not all MFA resists phishing. Push approvals, SMS codes and app-generated codes share one flaw: a human can be persuaded to hand the second factor to an attacker, or can approve a prompt just to make it stop. Attackers automate that persuasion with real-time relay pages and a follow-up phone call.
Two techniques are worth naming plainly. In prompt bombing, the attacker already holds valid credentials and triggers approval requests repeatedly, often late at night, then calls the employee posing as internal IT to talk them through accepting one. In real-time relay, a lookalike page proxies the password and the code through to the genuine login inside the valid window, and the session that comes back belongs to the attacker.
Voice cloning has made that follow-up call far more convincing. Any process where an approval, a reset or a payment change can be granted after a phone call from someone claiming to be the helpdesk will eventually be defeated.
What phishing-resistant authentication actually changes
Phishing-resistant methods bind the login to the origin and to a private key held in hardware. A passkey or security key will not release a signature to a domain that is not the real one, so a relay page gets nothing usable. There is no code for a human to read out and no prompt to approve under social pressure.
That single property removes an entire attack class:
- ▸Nothing reusable is transmitted. The secret never leaves the authenticator, so a stolen database or an intercepted request contains no credential to replay.
- ▸The origin check is enforced by the client, not by the user. Employees stop being the last line of defence against a convincing domain name.
- ▸Enrolment and recovery become the real project. An attacker who cannot phish a passkey will attack the reset path instead, so account recovery has to be as strong as the login it restores.
CISA publishes practical implementation guidance in Implementing Phishing-Resistant MFA, and the wider model of verifying every request instead of trusting a network position is set out in NIST SP 800-207 Zero Trust Architecture.
Sessions and tokens: the half of the problem nobody migrates
Rolling out passkeys while leaving session handling untouched upgrades the front door and leaves a window open. If a stolen cookie still grants months of access, you improved the ceremony and not the outcome. Session lifetime, revocation and step-up re-authentication belong inside the authentication project, not a later phase that never gets funded.
The rules that hold up in production:
- ▸Set an absolute maximum session lifetime, not only an idle timeout, and force a fresh authentication when it expires.
- ▸Re-authenticate for consequential actions: changing bank details, exporting the customer database, adding an administrator, altering MFA enrolment.
- ▸Make revocation real. One person must be able to kill one user's sessions across every application within minutes, and that path has to be tested rather than assumed.
- ▸Rotate and scope service credentials. A long-lived API key with full privileges is a password with no owner and no expiry date.
- ▸Log authentication events where someone actually looks, including successes, because a quiet success from an unusual device is the signal that matters most.
The migration order that does not stop the business
Sequence by blast radius, not by convenience. Administrators and finance first, then the systems holding customer data, then everyone else. Avoid a big-bang cutover on a legacy platform, and never leave the old path enabled as a permanent fallback, because attackers will simply use the fallback.
A sequence that survives contact with a real company:
1. Inventory every authentication path, including the ones your policy never mentions. Test what actually accepts a password today. 2. Close the bypasses. One legacy protocol or unprotected endpoint that skips MFA turns the whole rollout into theatre. 3. Enrol the highest-privilege accounts on phishing-resistant factors, with a second hardware key as the backup rather than a code by SMS. 4. Fix recovery before you fix login. Define an identity-proofing step for resets that a cloned voice cannot pass. 5. Shorten sessions and add revocation, then require step-up authentication on sensitive actions. 6. Retire shared and orphaned accounts, then move service credentials to scoped, rotating secrets. 7. Turn the old path off during a controlled window and see what breaks then, rather than discovering it during an incident.
Where the platform underneath cannot support any of this, authentication is not the project, the platform is. That decision is covered in Escaping SaaS: The Complete Guide to Migrating Your Business to Custom Software, and the ongoing work that keeps a fixed estate fixed is in What Website Maintenance Should Actually Include (and What You Are Probably Paying For). Stolen credentials are one of two dominant entry routes, the other being unpatched internet-facing services, so check the remote access products in the CISA Known Exploited Vulnerabilities catalogue against your own inventory this week.
How TuniCyberLabs helps
We audit every authentication path in your estate, including the undocumented ones, then migrate you to phishing-resistant login with session, token and recovery handling that matches. We sequence the work so staff keep working, and we switch the legacy path off properly instead of leaving it live as a convenience.
Tell us what your people log into today and we will map the real attack surface: talk to our engineers.