SAML gaps that turn into audit findings
A SAML integration that’s technically configured but not fully enforced creates a specific, quiet gap: some users authenticate through SAML as intended, while others continue using a standalone credential that was never actually disabled, either because it predates the SAML configuration or because someone found it more convenient and the platform never blocked the option. This gap doesn’t show up in normal daily use, since both authentication paths work fine from the user’s perspective. It shows up the moment a security review specifically asks how many accounts are actually authenticating through the identity provider versus a standalone credential, a question normal operations never naturally prompts anyone to ask.
Why partial enforcement is harder to catch than no enforcement at all
A tool with no SAML support at all is an obvious, unambiguous gap, easy to identify and easy to prioritize for remediation. A tool with SAML technically configured but not fully enforced is more insidious, since at a glance it looks like the requirement has been satisfied. A dashboard might show SAML is “enabled,” which can create false confidence that the governance gap is closed, when in reality a meaningful subset of accounts are still authenticating outside that system entirely. This kind of partial closure is genuinely harder to catch than a complete absence of the feature, precisely because it looks, superficially, like success.
The most common gaps that turn into findings
Pre-existing accounts never migrated. Accounts created before SAML was configured frequently continue on their original standalone credential indefinitely, since enabling SAML for new signups doesn’t automatically migrate accounts that already existed.
Standalone login left available as a convenience. Even after SAML is configured, some platforms don’t force its exclusive use, leaving a standalone login path active that users can, and sometimes do, continue using out of habit or convenience.
External and contractor accounts provisioned outside SAML. Agencies, freelancers, and contractors who aren’t part of the organization’s own identity provider are sometimes given standalone credentials as a practical workaround, creating a category of access that’s structurally outside SAML by design rather than by oversight.
No visibility into actual authentication method per account. Without specifically checking, an organization often has no clear, current picture of which accounts are actually authenticating through SAML versus a standalone credential, making the scope of any gap genuinely unknown until someone looks.
Time-pressured account creation bypassing the requirement. Accounts created quickly under deadline pressure, ahead of a launch or an urgent need, sometimes skip the SAML requirement for speed, with an intention to migrate later that frequently never actually happens.
How to actually catch this before a formal review does
The most direct approach is an authentication audit: reviewing every account with access to the video platform and specifically confirming which authentication method each one is actually using, not just whether SAML is configured at the platform level. This kind of account-by-account check is the only reliable way to distinguish genuine, complete enforcement from a partially closed gap that looks, at a glance, like success.
For organizations using Velo’s SAML 2.0 support, this audit is worth running specifically to confirm coverage extends across every account, not just new signups created after the initial configuration, since retrofitted enforcement rarely reaches every pre-existing account automatically.
Fixing it, and preventing the next gap
The immediate fix is the authentication audit and the migration it surfaces: identifying any account still using a standalone credential and migrating it to SAML, or, where genuinely not possible, such as certain external contractor scenarios, documenting a clear, deliberate exception rather than leaving it as an unnoticed gap. The durable fix is disabling the standalone login path entirely once migration is complete, removing the possibility of the same gap re-emerging as new accounts get created going forward.
Why external accounts deserve their own specific policy
Contractor and agency accounts are worth calling out as their own distinct category, since they’re structurally different from the rest of this gap. An employee on a standalone credential represents an oversight, someone who should have migrated but didn’t. An external party on a standalone credential often represents a genuine, unavoidable limitation, since many contractors and agencies simply aren’t part of the organization’s own identity provider and can’t authenticate through it the way an employee could. This doesn’t mean external access should go ungoverned, it means it needs its own explicit policy, a defined process for provisioning and, critically, deprovisioning external accounts, rather than being lumped into the same remediation effort as internal accounts that should have migrated but didn’t.
A short list of things worth checking during an authentication audit
- Pull a complete list of accounts with access to the video platform and check the actual authentication method each one currently uses.
- Specifically flag any account still using a standalone credential, distinguishing between accounts that should migrate and external accounts that may need a separate policy.
- Confirm whether the standalone login path can be fully disabled once migration is complete, or whether it remains available as a fallback.
- Review whether any accounts were created during a time-sensitive period with an intention to migrate later, and check whether that migration actually happened.
- Set a recurring cadence for this audit rather than treating it as a one-time check, since new accounts can reintroduce the same gap if enforcement isn’t airtight going forward.
Confirm every account is actually using SAML, not just that SAML exists
A SAML integration that’s configured but not fully enforced looks like success on a settings page while leaving a real gap in practice. Audit actual authentication method per account, not just platform-level configuration, before a security review does it for you.
Try Velo for free · See how it works
Related reading
- What SAML actually fixes: IT blocking a tool because it does not support enterprise login
- SAML claims worth verifying before IT blocking a tool because it does not support enterprise login becomes a blocker
- What happens when SSO is an afterthought
- RBAC gaps that turn into audit findings
About the author
Ritu Parakh is Growth Lead at Velo, the AI video messaging platform that turns a screen recording, a deck, or a URL into a polished, narrated video - and an editable written doc. She writes about video for demos, onboarding, training, and enablement. Connect on LinkedIn