Just spent twenty minutes crawling MeetGeek's site trying to figure out their enterprise SSO story before throwing my hands up. Their "Enterprise Security" page is a masterclass in saying everything and nothing at all.
We get the standard "military-grade encryption" and "GDPR compliant" boxes, ticked with bold checkmarks. But when it comes to the actual identity provider integration—the thing that actually matters for an enterprise deal—the details vanish. Is it SAML 2.0? OIDC? Do they support SCIM for user provisioning? Is it an extra-cost add-on, or is it bundled in the "contact us" plan? The page just says "Single Sign-On (SSO)" in a feature list, like it's a checkbox next to "unlimited transcripts."
If you're going to have an enterprise security page, the SSO section shouldn't be a dead end. It's the first thing our infosec team asks for. Right now, it feels like they're using "enterprise" as a pricing tier label, not a feature set. Anyone from their side care to clarify, or is the real spec sheet still buried in a sales PDF somewhere?
just sayin'
Data over dogma.
I've run into this exact pattern more times than I can count. The phrase "military-grade encryption" has become such a generic, meaningless security theater term that it's a red flag when it's front and center while IdP details are absent.
You're spot on about the critical questions: SAML 2.0 versus OIDC, SCIM support, and the cost structure. In my experience, when those specifics are missing from public documentation, it often means the SSO implementation is either a recent bolt-on with limited configuration, or it's gated behind a sales conversation where it becomes a negotiating point for the "enterprise" contract. The absence of SCIM is particularly telling for a true enterprise-ready service, as manual provisioning doesn't scale.
This approach creates unnecessary friction in the evaluation phase. A security team will immediately request a detailed architecture diagram and IdP configuration guide, which you shouldn't need a signed NDA to access.
Oh, this is the classic "checkbox SSO." I'd bet real money their implementation is SAML 2.0 via a third-party middleware service, and SCIM is nowhere on the roadmap. You find the actual details buried in a Knowledge Base article titled "How to set up SSO with Okta," which only exists because a big client demanded it last year.
The "contact us" plan line is the real kicker. That's sales-speak for "we'll use enabling SSO as a concession to justify the 300% price hike for the 'Enterprise' SKU." If it were a standard feature, the IdP configuration docs would be public.
Your infosec team is right to ask. A real enterprise security page would have a technical overview or a whitepaper link. The absence tells you everything about how they view "enterprise" - it's a billing concept, not an architectural one.
APIs are not magic.
Exactly. That buried KB article is the tell. I've had to reverse-engineer "enterprise" SSO from those more than once.
If it's a third-party middleware, you also inherit its limitations. No custom attribute mappings, funky SP-initiated flow behavior, and their support team just points you to the middleware's docs.
And the 300% hike isn't just for the feature. It's for the privilege of getting an engineer who can read the logs when it breaks.
Five nines? Prove it.