How to Audit SSL VPN Accounts for Non-SAML Logins

To audit SSL VPN logins for non-SAML access, compare what each account was supposed to use against what the logs say it actually used. Export the appliance's user and authentication settings, pull successful VPN logins for the longest period you retain, and flag every session by a SAML user that did not come through the identity provider. The exploited SonicWall flaw CVE-2026-19868 makes this check urgent on any SAML-protected VPN.

How do you audit SSL VPN logins for non-SAML access?

Build a list of accounts that should only use SAML, then search VPN authentication logs for successful logins by those accounts through any other method. Each match is a finding that needs an explanation, even if it turns out to be harmless.

The steps below use general terms because field names and menus vary by vendor and firmware. Use your vendor's log reference to map each term to the field your appliance records. For SonicWall context, see our news article on CVE-2026-19868 and the SAML MFA bypass.

Step 1: Patch first and preserve what you have

Do not hold an upgrade for the audit if the appliance is on an exploited build. Export logs and a configuration backup first, because logs stored only on the appliance may not survive for long, then proceed with the upgrade.

Keep the exports somewhere the VPN appliance and its administrators cannot alter them. A copy on a separate log server or SIEM is best. Our guide to the cyber insurance SIEM and logging question covers what to keep and how to prove it.

Step 2: List every authentication source

Write down each authentication source configured on the appliance: SAML, local users, LDAP or Active Directory, RADIUS, TACACS+ and anything else in use. Note which ones can be used for VPN access, as opposed to administrator login or another service.

Vendor terminology can hide useful detail here. SonicWall's 2025 SSLVPN notice, for example, says only users with a password set on the firewall's management interface count as local users. Auto-generated or locally duplicated LDAP and RADIUS users have no password stored in SonicOS. A long user list on the firewall may therefore contain far fewer local passwords than it first appears to.

Step 3: Build the expected state

Create a simple spreadsheet with one row per account that can reach the VPN:

• Username, in every form the appliance recognizes (for example, UPN and SAM account name).
• The method the account is supposed to use.
• Whether a non-SAML credential exists for the account.
• The owner, and the reason for any exception.
• Last successful login and method.

Include disabled-in-theory accounts, former staff, contractors, vendor support accounts and anything migrated from older hardware. The username forms matter because CVE-2024-12802, an earlier SonicWall MFA bypass, depended on how UPN and SAM account names were handled.

Step 4: Compare logs with the expected state

Export successful VPN authentication events and join them to your spreadsheet by username. Normalize usernames first (case, domain prefix, and UPN or SAM form) so one person does not appear as three accounts.

Flag these results for review:

1. A SAML-only account that logged in through any other method.
2. A successful VPN session with no matching sign-in on the identity provider side at about the same time.
3. An account with a non-SAML credential that has never used it. Nothing happened yet, but the credential should go.
4. Logins from new source addresses or countries, or at hours the user does not normally work.
5. A burst of failed logins followed by a success on the same account.

The second check is the most useful one because it does not depend on the appliance recording the method accurately. If the VPN recorded a session and the identity provider has no record of authenticating that user, you have a question to answer.

What counts as a suspicious non-SAML login?

Any successful login by a SAML-only account through another method should be treated as suspicious until someone can explain it. A documented break-glass test with a named person and a date is an explanation; "probably an old setting" is not.

How far back should the audit go?

Go back as far as your logs allow. SonicWall has not published a start date for exploitation of CVE-2026-19868, so there is no known safe cutoff, and a short retention window is itself a finding to report.

Step 5: Investigate each exception

For each unexplained session, work out what happened in order:

1. Ask the account owner whether the session was theirs, using a channel other than the possibly compromised account.
2. Record the source address, session start and end times, and the internal addresses the session reached.
3. Review firewall, directory and endpoint logs for the internal systems that session touched.
4. Look for changes on the appliance: new local accounts, newly enabled authentication methods and new VPN authorizations.

If you cannot rule out misuse, treat the account as compromised. Reset its credentials and end active sessions. SonicWall's 2025 guidance also calls for rotating exposed credentials such as LDAP bind credentials if an administrator account may have been compromised. Our walkthrough on how to detect Ivanti Connect Secure exploitation shows a similar evidence-first approach for another VPN product.

Step 6: Remove what you do not need

Disable or remove every non-SAML credential that has no documented owner and purpose, and take VPN access away from any account that does not need it. Keep a tested administrative path before you make changes, so a mistake or an identity provider outage does not lock everyone out.

Then re-test. Use a non-production account to try each remaining route, and confirm that the login either requires your identity provider or fails. If you are unclear on why a single password path counts as a weakness, read what CWE-308 single-factor authentication means.

Step 7: Turn the audit into an alert

A one-time audit goes stale the first time someone adds a user. Forward VPN authentication logs off the appliance and alert on a successful login by a SAML-only account through any other method. Repeat the account comparison quarterly, and after every firmware upgrade or hardware migration. The longer-term decision about these paths is covered in why SAML MFA fails when other login paths remain.