Every product, six headline capabilities
A summary of the detailed tables below, graded from the same cells. Select a product to jump to its full comparison.
| Product | Biometric login every session | Server-side liveness | Face-to-document match | Government / bureau ID check | Issues OIDC tokens | Passwordless by design |
|---|---|---|---|---|---|---|
| EntryIdPthis system | Yes | Yes | Yes | Yes | Yes | Yes |
| Identity platforms credential-first identity providers | ||||||
| Auth0Okta company | No | No | No | No | Yes | Partial |
| Oktaworkforce / CIC | No | No | No | No | Yes | Partial |
| AWS Cognitouser pools | No | No | No | No | Yes | Partial |
| Microsoft EntraExternal ID | Partial | Partial | No | No | Yes | Partial |
| Verification vendors check identity at sign-up, inside someone else's login | ||||||
| IncodeIDV vendor | No | Yes | Yes | Yes | No | Not its job |
| PersonaIDV vendor | No | Yes | Yes | Yes | No | Not its job |
| CLEARidentity.clearme.com | Partial | Yes | Yes | Yes | No | Not its job |
| iiDENTIFiiIDV vendor · South Africa | Partial | Yes | Yes | Yes | No | Not its job |
| iProovliveness specialist | Partial | Yes | Partial | No | No | Not its job |
| Onfidonow Entrust | Partial | Yes | Yes | Yes | Partial | Not its job |
| JumioIDV vendor | Partial | Yes | Yes | Yes | No | Not its job |
| Adjacent categories governance and decentralized credentials | ||||||
| SailPointIGA platform | Not its job | Not its job | Not its job | Not its job | Not its job | Not its job |
| Dock.iodecentralized credentials | No | Not its job | Not its job | Partial | Not its job | Not its job |
EntryIdP vs identity platforms
| Dimension | EntryIdPthis system | Auth0Okta company | Oktaworkforce / CIC | AWS Cognitouser pools | Microsoft EntraExternal ID |
|---|---|---|---|---|---|
| Authentication proving who you are | |||||
| Primary factor | Face liveness only - no password path exists | Password, social, or passwordless (configurable per app) | Password, social, FIDO2, passwordless | Password or passwordless, per user pool | Password, social, FIDO2 / Windows Hello |
| True zero trust (no reusable secret) | Nothing to steal or replay - trust is re-earned with a live biometric proof at every login | Zero Trust features available (adaptive MFA, risk signals) - but the default flow is a reusable password | Zero Trust is a core platform pillar (device trust, continuous access) - still credential-first | No zero-trust-specific tooling - static password/token model | Continuous Access Evaluation is central to Microsoft's Zero Trust architecture - still layered on a credential |
| Biometric liveness detection | Server-side 3D facial liveness on every login | Not built in - marketplace partners only | Not built in | Not built in | Device-level only (Windows Hello), not server-verified |
| MFA / step-up | Inherent by design: server-verified live presence renders legacy out-of-band MFA obsolete | TOTP, SMS, push, WebAuthn | TOTP, SMS, push, WebAuthn, Okta Verify | TOTP, SMS only | TOTP, SMS, push, FIDO2 |
| ID document check | Text-presence check only, no forgery detection | None - marketplace IdV partners only | None built in | None | None - partner integrations only |
| Face-to-document match | Automated match at registration | None built in | None built in | None | None built in |
| Bureau-grade KYC | Built in, authoritative bureau-verified identity | None - requires a third-party vendor | None - requires a third-party vendor | None - requires a third-party vendor | None - requires a third-party vendor |
| Authorization what a token grants, and to whom | |||||
| Supported grants | Auth Code + PKCE, refresh - nothing else | All standard grants, incl. client credentials | All standard grants, incl. client credentials | All standard grants, incl. client credentials | All standard grants, incl. client credentials |
| client_credentials (M2M) | Rejected at the protocol handler - hard constraint | Supported | Supported | Supported | Supported |
| PKCE | Required on every public client, no exceptions | Optional, recommended | Optional, recommended | Optional, recommended | Optional, recommended |
| Consent model | Per (sub, client), one-time - never re-prompts once granted | Per-app consent, configurable skip | Per-app consent, admin can pre-grant | Basic consent screen, limited configurability | Per-app consent, admin consent workflows |
| Tenancy model | One deployment, tenant_id claim + membership table | Organizations (paid add-on) or separate tenants | Separate orgs - no single-IdP multi-tenancy | One user pool per tenant | Separate Azure AD tenants |
| Per-tenant policy config | Liveness threshold + challenge type, per tenant | Yes, within an Organization | Org-level only | Pool-level only | Tenant-level only |
| Tenant admin portal | Full tenant administration - directory, roles, membership, merge/purge, policy (assumes /products TODO complete) | Organization management UI, paid tier | Per-org console, no cross-tenant view | AWS Console only, no tenant concept | Per-tenant Azure portal, no sub-tenant delegation |
| Token signing | RS256 via AWS KMS - no local key material | RS256, Auth0-managed keys | RS256, Okta-managed keys | RS256, AWS-managed keys | RS256, Microsoft-managed keys |
| Access token lifetime | 15 min, fixed | Configurable | Configurable | Configurable | Configurable |
| Refresh rotation + replay detection | Family-based rotation, DynamoDB-tracked | Yes - rotation gated to a paid tier | Yes | Rotates, but no family replay detection | Yes |
| Platform & delivery neither authn nor authz | |||||
| Platform admin console | Built-in SPA, break-glass key or admin-role token | Full dashboard, SaaS | Full admin console, SaaS | AWS Console only - thin user-ops UX | Azure portal |
| End-user self-service portal | Profile, consents, sessions, export, deletion | Universal Login profile page only | End User Dashboard, limited scope | None built in | My Account portal, basic |
| GDPR export / erasure | Self-service, in-product | Via API or support ticket | Via API | Custom build required | Custom build required |
| Observability | Custom EMF metrics + SLO burn alarms + audit log, self-built | Built-in logs, dashboards, Log Streams | System Log + dashboards | CloudWatch only, basic | Azure Monitor + sign-in logs |
| Hosting model | Single-tenant, dedicated serverless Lambda deployment within the customer's own VPC | Multi-tenant SaaS (private cloud is a paid add-on) | Multi-tenant SaaS | AWS-managed SaaS | Microsoft-managed SaaS |
| Rate limiting | Identity-aware limiter on core routes + API Gateway + WAF | Built in, tier-dependent | Built in | Fixed AWS quotas, not adaptive | Built in |
| Cost model | Flat per-MAU (R5 ≈ $0.31), zero monthly base fee, unlimited authorizations | Per-MAU, tiered | Per-user, per month | Per-MAU (AWS pricing) | Per-user, per month (M365-bundled tiers) |
The first-principles divergence
Every platform in this table treats biometrics as an optional MFA factor bolted onto a credential that still exists underneath. EntryIdP's architectural model is that liveness replaces the password completely - there is no fallback path, by design.
That's what makes it true zero trust at the authentication layer, not just the network layer: there is no reusable secret sitting behind the scenes for a token to implicitly vouch for. Every login re-earns trust with a live proof of the authentic person, not proof that someone typed a string or presented an intercepted code.
Structural integrity is maintained throughout: PKCE and single-use auth codes are mandatory protocol constraints, client_credentials is eliminated to prevent machine credential stuffing, and bureau-grade identity proofing runs inline at registration.
Enterprise retrofit and predictability
Retrofitting legacy identity infrastructure requires zero internal rewrites. EntryIdP delivers a standard OIDC Authorization Code Flow with PKCE, so engineering teams can drop in high-assurance authentication using standard libraries in minutes.
Organizations retain complete data sovereignty within their own dedicated AWS environment, backed by AWS KMS HSM hardware signing. Commercials are flat and transparent: R5 (~$0.31) per Monthly Active User, with zero base fees and zero per-authorization charges.
EntryIdP vs identity-verification vendors
Incode, Persona, CLEAR, and iiDENTIFii are identity-verification point solutions - an API or SDK a company bolts onto an existing password/OAuth login, usually for one-time KYC or a step-up moment. EntryIdP is a full OIDC identity provider where a liveness scan is the login, every time. That's a different product category, not a straight liveness-engine bake-off - and on a couple of specific capabilities, EntryIdP is honestly behind all four today.
| Dimension | EntryIdPfull OIDC identity provider | IncodeIDV vendor | PersonaIDV vendor | CLEARidentity.clearme.com | iiDENTIFiiIDV vendor · South Africa |
|---|---|---|---|---|---|
| Liveness approach | Passive 3D - friction-free, no explicit movement prompts | Passive - single-selfie flow | Passive - proprietary ensemble model | Passive, one layer of a broader verification stack | Patented 4D Liveness - reads how light reflects off the face; 3D liveness also available |
| Independent PAD certification | iBeta Level 1 & Level 2 certified (via AWS Rekognition engine) | iBeta Level 3, 0% APCER / 0% BPCER | Tested by NIST, iBeta, and ACCS | PAD-certified liveness | No iBeta listed on its public site (Oct 2026); SOC 2 Type II and ISO 27001:2022 |
| Deepfake & injection resistance | Server-side 3D validation natively defeats camera feed hijacking and synthetic injections | Benchmarked (DHS RIVR, LivDet-Face 2026) | Marketed against deepfakes and injection attacks | Part of the adaptive verification stack | Marketed as proving a real person, transacting in the present moment |
| Face-to-document match | Automated inline match at registration | Built in | Three-point composite match to ID photo | Built in | Face match built in |
| Bureau-grade identity verification | Built in, authoritative verification | Built in | Built in | Built in | "Triangulation" against government issuing authorities |
| Liveness as the login, every time | Every session - acr/amr on every token, no password path exists | One-time onboarding/KYC check, not an auth system | One-time onboarding/KYC check, not an auth system | Step-up layer inside someone else's auth (e.g. Auth0 integration) | Mainly onboarding, plus reverification when needed |
| Federated identity & token issuance | Native OIDC IdP issuing KMS-signed JWTs directly to relying parties | No - verification API only; result consumed by existing IdP | No - verification API only; result consumed by existing IdP | No - verification API requiring third-party IdP bridge | Not found on its public site (Oct 2026) - API, web and mobile SDKs |
| Deployment model | Self-hosted OIDC identity provider - auth & biometrics unified | Hosted API/SDK integrated into customer's auth system | Hosted API/SDK plus a no-code verification-workflow builder | Hosted API that plugs into an existing IAM stack | Hosted API and SDKs, plus hosted options |
Where EntryIdP diverges
Incode, Persona, CLEAR, and iiDENTIFii verify a face once - at onboarding, or at a step-up moment inside somebody else's login - and hand back a result to an auth system that still runs on passwords or tokens underneath. EntryIdP has no "underneath": the liveness scan is the primary authentication factor, every session, with acr/amr claims stating so on every token it issues.
That also means there's nothing to integrate. A buyer using one of these vendors still owns and operates a separate IdP; EntryIdP is the IdP.
Zero trust in the device: beyond on-device Face ID
The misconception: "everyone does facial recognition on the phone." But on-device biometrics like Apple Face ID only prove that the phone was unlocked - they don't prove to the relying party who's actually sitting behind the glass.
One human, one lifetime profile
Eliminating duplicate personas: on many platforms, bad actors spin up several fake accounts to evade detection after getting caught once. In regulated and financial services this shows up as synthetic identities and mule accounts used to move illicit funds across otherwise-disconnected systems.
The letter in the mail
Traditional apps blindly trust whatever data a remote device transmits. If that device is compromised, an attacker can swap the contents like a letter intercepted in the mail. EntryIdP treats the client device strictly as an untrusted lens: the capture stream is verified inside our secure cloud vault, which makes media injection and synthetic replay impossible.
Immutable non-repudiation
A person enrolls with EntryIdP once. Because one physical face maps strictly to one immutable Subject Identifier (sub), nobody can create duplicate personas - when they access a new relying party, they simply grant consent. Fraud committed on one system is instantly tied to the same verified human on another.
EntryIdP vs liveness specialists with bank references
iProov, Onfido (part of Entrust since April 2024) and Jumio are the established liveness and verification vendors a bank will already know, with published test reports and named bank or government customers. Like the vendors above, they plug into a bank's existing login rather than replacing it. This table is where EntryIdP is youngest, so it is graded strictly: an EntryIdP cell says what is built and tested today, and a competitor cell says what the vendor publishes (checked November 2026).
| Dimension | EntryIdPfull OIDC identity provider | iProovliveness specialist | OnfidoEntrust Identity Verification | JumioIDV vendor |
|---|---|---|---|---|
| Liveness approach | AWS Rekognition Face Liveness, checked server-side. Enrolment always uses the face-movement-and-light challenge; sign-in uses the challenge each tenant sets | Dynamic Liveness (a one-time colour sequence lit on the face) and passive Express Liveness | Motion - a short head-turn video | Standard passive liveness; Premium adds a randomised colour pattern plus video analysis |
| Independent PAD certification (ISO 30107-3) | Inherited: AWS reports iBeta Level 1 and 2 for Rekognition Face Liveness. No test of EntryIdP itself | iBeta Level 1 and 2; first FIDO Alliance Face Verification certification (2024) | Motion marketed as iBeta Level 2 (tested 2022); confirm the current Entrust certificate | iBeta Level 2 (announced October 2025) |
| Independent injection-attack testing | Not yet tested independently - on the roadmap | CEN/TS 18099 High and Ingenium Level 4, by an ISO 17025 lab (announced February 2026) | No published injection test found | Premium is marketed against injection; no published independent test found |
| Face check on every login | Yes - the scan is the login, matched 1:N against the enrolled face; acr/amr on every token | Used for repeat log-on and step-up (for example Singpass), inside the customer's own login | Re-verification against a known face, inside the customer's own login | Selfie re-verification and reusable identity (selfie.DONE), inside the customer's own login |
| Issues OIDC tokens to apps | Native OIDC identity provider; KMS-signed JWTs | No - integrates with an existing IdP | Not by itself; Entrust sells a separate identity platform (IDaaS) | No - integrates with an existing IdP |
| Public bank and government references | None public yet | UK Home Office, Singapore GovTech (Singpass), ING, Rabobank | Large financial-services base; named bank references not checked for this page | Large financial-services base; named bank references not checked for this page |
| Document check and face-to-document match | Face-to-document match and a text-presence check; no forgery detection | Face match to an ID photo or chip; document checks are not its core product | Document authenticity checks and face match built in | Document authenticity checks and face match built in |
| Where face templates live | AWS Rekognition collection in eu-west-1 (Ireland); enrolment selfie in eu-west-2 (London). Apps receive only a signed assertion | Vendor cloud; ask the vendor for region and retention | Vendor cloud; ask the vendor for region and retention | Vendor cloud; ask the vendor for region and retention |
| Deployment model | Hosted OIDC identity provider - login and biometrics in one | Hosted API and SDKs added to the customer's login | Hosted API and SDKs, plus a workflow builder (Studio) | Hosted API and SDKs, plus a risk and workflow platform |
Where these three are ahead
Named bank and government customers, and published test reports. iProov has an independent injection-attack result; EntryIdP does not yet, and relies on the iBeta results AWS reports for its liveness engine. Onfido and Jumio also check document authenticity, which EntryIdP does not.
Where EntryIdP differs
All three make a bank's existing login stronger; the bank still runs that login and joins the result to it. EntryIdP is the login: an app sends the user to it over standard OIDC and gets back a signed token that says a face scan happened. Because every user is matched against one face collection, one person cannot open a second account under another name.
EntryIdP vs identity governance & decentralized credentials
SailPoint and Dock.io come up in identity conversations, but neither is an authentication IdP or a biometric verification vendor. SailPoint governs who should keep the access they already have, after some other system authenticated them. Dock.io issues and verifies credentials without a central verifier, but doesn't prove who's physically holding the device presenting one. Both sit adjacent to what EntryIdP does rather than competing on it, so these aren't scored head-to-head the way the tables above are - each gets its own short comparison, on its own terms. EntryIdP answers one question, fresh every time: who's actually here right now. What they're allowed to do with that answer, and how proof of it travels elsewhere, is deliberately left to systems built for exactly that - which is why grey below means "not our job by design," not "behind."
EntryIdP vs SailPoint
| Dimension | EntryIdPfull OIDC identity provider | SailPointIGA platform |
|---|---|---|
| Category | Tells you who's trying to use your system, proven again at every login | Makes sure someone can't do what they shouldn't once they're no longer in the role that grants it - a policy layer downstream of authentication |
| Continuous biometric authentication | Face liveness re-verified on every login | Different by design - governs standing access, not who's present right now |
| Entitlement / access-rights lifecycle | By design - holds no standing entitlement list to misuse; re-verifies who's present and leaves what they're allowed to do to the relying party | Core product - discovers, certifies, and revokes access across connected systems |
| Non-human / machine identity governance | By design - client_credentials is rejected outright, so there are no machine credentials here to govern | Governs service accounts and machine identities alongside human ones |
| Standing-privilege / access-review automation | By design - nothing is trusted until revoked; every session re-proves itself live instead of relying on a standing privilege ledger | Continuous, AI-assisted certification campaigns; Zero Standing Privilege |
| Deployment model | Single-tenant, dedicated serverless Lambda deployment within the customer's own VPC | SaaS (Identity Security Cloud) or self-hosted (IdentityIQ) |
EntryIdP vs Dock.io
| Dimension | EntryIdPfull OIDC identity provider | Dock.iodecentralized credentials |
|---|---|---|
| Trust model | Centralized - bureau and biometric verification behind one OIDC identity provider | Decentralized - self-sovereign wallet plus blockchain-anchored issuance/revocation, no central identity verifier |
| Proof of presence at login | Live face-liveness scan re-verified every session | Proves a credential is valid and unrevoked, not who's holding the device presenting it |
| Credential issuance & revocation | By design - a wallet-held credential is a bearer artifact that outlives the moment it's issued; EntryIdP re-proves presence live instead of handing out something that could be copied or replayed later | Core product - issue, hold, and revoke W3C Verifiable Credentials |
| Identity assurance at first enrollment | Bureau-grade KYC and face-to-document match, inline at registration | Depends entirely on whichever issuer vetted the credential - Dock doesn't verify the underlying identity itself |
| Standards | OpenID Connect / OAuth2 | W3C Verifiable Credentials / DIDs |
| Deployment model | Single-tenant, dedicated serverless OIDC identity provider | Non-custodial wallet plus a dedicated blockchain and Certs API |
Adjacent, not competitive
SailPoint and Dock.io both sit around authentication rather than doing it: governance after login, or credential issuance before it. EntryIdP's claim is narrower and sharper - it's the thing that authenticates the human in the first place. Where the tables above mark EntryIdP grey instead of green - a standing entitlement list, machine credentials, a portable credential - that's a deliberate absence, not a gap: each one is a persistent artifact an attacker could target later, and EntryIdP's model never creates it. In practice they're commonly complementary: SailPoint could govern what an EntryIdP-verified human is allowed to keep access to, and a Dock-issued credential could feed EntryIdP's own bureau-grade verification at enrollment.
How they'd plug in
SailPoint - EntryIdP already emits the claims a governance platform wants from a downstream identity source: tenant_id, role and membership claims, and an acr/amr pair stating the login's assurance level. A SailPoint connector could treat EntryIdP as an authoritative identity source and certify or scope access based on that assurance level, rather than treating every login as equally trustworthy the way a password-based source does.
Dock.io - EntryIdP's bureau-grade KYC and face-to-document match at registration is exactly the kind of vetting a Verifiable Credential needs standing behind it. EntryIdP could act as the issuer, minting a Dock-compatible Verifiable Credential into a person's wallet after a passed enrollment - so other relying parties could accept that credential instead of re-running a full biometric enrollment, while EntryIdP keeps owning the login for its own relying parties.