What Is CWE-308? Single-Factor Authentication Explained

CWE-308 single-factor authentication is the weakness class for a product that relies on one authentication factor, such as a password, where the security context calls for more than one. MITRE lists the consequence plainly: if that one secret is compromised, full authentication is possible. The category matters to IT teams because it often appears in systems where MFA is switched on and working for most logins, while a single path still accepts a password alone.

What is CWE-308?

CWE-308 is the MITRE Common Weakness Enumeration entry titled "Use of Single-factor Authentication." It describes software that authenticates with one factor in a situation that should require several, which means one stolen secret is enough to log in.

MITRE places it under CWE-654, reliance on a single factor in a security decision, and CWE-1390, weak authentication. It also links it as a peer of CWE-309, use of a password system for primary authentication. Those relationships tell you how to think about it: the problem is the dependence on one secret, and the strength of that secret is a separate question.

How does CWE-308 differ from a weak password flaw?

A weak password flaw concerns the quality or storage of a secret, while CWE-308 concerns how many independent proofs the system demands. A long, random password still fits CWE-308 if it is the only thing standing between the internet and an administrator session.

That distinction changes the fix. Password rotation and complexity rules reduce the odds of compromise, but they leave the single point of failure in place. Adding an independent factor, and enforcing it on the server side, removes it.

Where single-factor authentication shows up in practice

Few modern enterprise products lack MFA outright. The weakness usually appears at the edges of a product that does support it:

• Alternate login methods. An appliance enforces MFA through an identity provider, but it also accepts local or directory credentials for the same user.
• Administrative interfaces. The user portal requires MFA while the management console, CLI or API accepts a password.
• Migrated accounts. Accounts from an older platform arrive with their passwords intact and stay usable after the new policy goes live.
• Service and emergency accounts. These are often exempted from MFA for practical reasons, then forgotten.
• Per-identifier policy. MFA is bound to one form of a username, and another form of the same account is treated separately.

The last item has a real example. ReliaQuest and Cybersecurity Dive described CVE-2024-12802 as a SonicWall SSL-VPN MFA bypass tied to how the appliance handled UPN and SAM account names with Active Directory.

CVE-2026-19868 as a worked example

The exploited SonicWall SAML bypass, CVE-2026-19868, carries the CWE-308 label. According to its CVE record, a user with valid credentials for an alternate authentication method may bypass SAML controls on the SonicOS SSLVPN service, and with them any MFA that SAML enforced.

It illustrates the usual pattern. The organization configured strong authentication and could show a working MFA prompt to an auditor. The product still had a route that did not depend on that prompt. Testing the normal login flow would not reveal the problem, because the normal flow behaves correctly.

The CWE label also clarifies what the flaw does and does not do. The attacker needs a valid secret, so this is different from a bug that hands out sessions with no credentials at all. Password theft, reuse and spraying become far more dangerous, because a password alone is now enough.

Why does MFA not rule out CWE-308?

MFA only protects the login flows that actually enforce it. If any route to the same account accepts one factor, an attacker can use that route, and the strength of the MFA on the other route makes no difference.

For this reason, "we have MFA" and "every login requires MFA" are different statements. Security questionnaires often blur the two, and our guide on answering the MFA section of a cyber insurance application deals with the same gap from the paperwork side.

How to find CWE-308 in your environment

Start from accounts and systems, and work outward from what each one will actually accept:

1. List every internet-facing login: VPN portals, firewall management, email, remote support tools, cloud consoles and vendor portals.
2. For each one, list every authentication source it is configured to use. Include local users and directory integrations, as well as the SSO connection.
3. Test with a non-production account. Try each configured route and record whether a second factor was required.
4. Compare the results with authentication logs. Logs show which methods real users have been using, including methods nobody remembered enabling.
5. Record exemptions with a named owner and a reason, then review them on a schedule.

For VPN appliances, our walkthrough on how to audit SSL VPN logins for non-SAML access applies these steps to log data.

How do you fix CWE-308?

Require independent authentication factors on the server side for every route that reaches the account, and remove any route that cannot enforce them. MITRE's mitigation is the same idea: use multiple independent authentication schemes so one compromised secret does not expose the system.

If you are building software, enforce the factor requirement at the point where the session is issued, so no login method can reach a session without it. If you are buying software, ask vendors to describe what happens to local and directory credentials once SSO is enabled, and test the answer yourself.

Vendor flaws such as CVE-2026-19868 still need a patch, since no configuration you control can fully replace the vendor's enforcement. Reducing unnecessary login methods then limits the damage from the next one. Our planning piece on why SAML MFA needs other login paths closed covers that decision.