01
What moves, and what stays where it is
Nothing changes for the applications. They keep the Entra ID configuration they have, whether they are Microsoft's own or line-of-business software, and Entra ID goes on issuing the token they consume. What federates outward is the authentication event, and only that.
That event is where the current attack pressure sits. Microsoft's own Digital Defense Report recorded 146% year-over-year growth in adversary-in-the-middle phishing in 2024. An adversary-in-the-middle attack relays a genuine sign in through a proxy and steals what comes out of it, which is why bolting another prompt onto a password rarely moves the number.
Federating to an external identity provider over open standards is native Entra ID behavior, so the deployment footprint here is two sets of console settings and nothing running inside the tenant.
Entra ID remains in charge
Conditional policy, group membership and application assignment continue to be evaluated where they are today. SenseCrypt takes none of that over and does not need to know about it.
SenseCrypt is the authentication event
Entra ID redirects, the check completes on the enrolled phone, and a signed ID token or SAML assertion returns naming that user. Entra ID validates the signature before it acts on anything inside.
Scoped to the users you choose
A federation can be aimed at one group, so a pilot population moves to face login while every other account signs in exactly as before. Backing out is a policy edit rather than an account migration.
No parallel session to reason about
SenseCrypt keeps no SSO session for end-user authentication. The session your people hold is the Entra ID session, and its lifetime is governed by your Entra ID policy alone.
02
Choosing the federation protocol
You need one link, not two. OpenID Connect is the lighter build and the better default for a new connection: Entra ID reads a discovery document, PKCE (RFC 7636) pins each authorization code to the client that began the exchange, and pushed authorization requests (RFC 9126) keep the request parameters off the front channel entirely.
If the Entra estate is already full of SAML connections, use SAML 2.0 and keep this one shaped like its neighbors. What differs is certificate housekeeping, not what the user does.
Trust in both directions rests on published keys rather than on a secret exchanged out of band, which is what makes rotation an ordinary maintenance task instead of an outage.
OIDC: discovery carries the configuration
Endpoints and verification keys are published in the SenseCrypt discovery document, so a single URL configures the bulk of the connection and a key rotation passes without anyone editing Entra ID.
SAML 2.0: metadata in both directions
Two documents establish the trust. The SenseCrypt file names the sign-in endpoint and the signing certificate; Entra ID returns its own service provider description. Load each into the opposite side.
Everything returned is signed
SenseCrypt signs every ID token and every assertion it issues, and Entra ID checks that signature against the published key. Trust is therefore anchored in a verification key and not in a domain name anyone can imitate.
Attribute mapping decides what downstream sees
The claims SenseCrypt emits, roles and permissions included, have to land on the Entra ID attributes your applications already read. Bind on an identifier that survives a change of name or email address.
03
Getting the connection live
Attribute mapping consumes most of the elapsed time. A federation can be technically flawless and still hand your applications a user record they cannot use, if the identifier or the role values arrive in the wrong fields.
Prove it with a disposable account and a physical handset before any policy points real people at this. Enrollment is the step teams consistently underestimate, and it is the only part of the change that meets every user personally.
- In the SenseCrypt console, create the relying party record for your Entra tenant.
- Collect the discovery URL for an OIDC link, or the metadata file for a SAML 2.0 one.
- On the Entra side, register SenseCrypt on the external identity provider screens.
- Line the emitted claims up with Entra ID user attributes, roles included.
- Scope the policy so that only the pilot group reaches the new provider.
- Switch on SCIM 2.0 so that joiner and leaver changes do not need a ticket.
- Enroll one test account, then complete a face login on a real handset.
04
What the change buys you
The mechanism is subtraction. With neither a password nor a one-time code in the sign-in flow, there is no shared password for a caller to extract. QR requests are not origin-bound; phishing resistance belongs to the passkey path. Proof becomes a liveness-checked match performed on a phone enrolled to one person.
Against relay attacks specifically, the honest answer names a path. Where the passkey path is in use, WebAuthn binds each signature to your origin, so a proxy sitting between the user and your tenant walks away with something that verifies nowhere it can reach. That is the property CISA describes as phishing-resistant MFA.
Everything else the platform does arrives with the federation instead of sitting behind a higher tier, since what you are connecting to is a complete identity provider rather than an extra factor attached to one.
Nothing to phish, nothing worth relaying
No password and no one-time code exists in the flow. On the passkey path, origin binding means a relayed sign in yields a signature that is invalid for your origin. On the QR path the credential is absent altogether, which is a different property, and it is described as one. Phone sign-in also combines a live face check with a key bound to the enrolled device.
What is stored, precisely
IdP retains quantum-safe, sealed, biometric-free, disposable face tokens and their verifier challenges. Standard OIDC/SAML account records, device public keys, sessions, logs and encrypted tenant signing keys also persist. No face images or templates are retained in the documented phone flow. Licensed on-premises Webcam processes captures inside the customer deployment. A breach may expose sealed, biometric-free, disposable face tokens and account records; its impact depends on the compromised data and key custody.
Where the biometric testing stops
Liveness detection tested by iBeta to ISO/IEC 30107-3 Levels 1 and 2 has a defined scope: artifacts presented to the lens, not software injected behind it. Face recognition is evaluated in the NIST Face Recognition Technology Evaluation under Seventh Sense's own name, participation since 2021. Evaluation is not certification, and we would ask you to hold every biometric vendor to that wording.
Included, not upsold
Multi-tenant isolation, role-based access control, CIBA and SCIM 2.0 provisioning belong to the platform rather than to a tier above it. Seats list at one dollar per user each month against a 20-seat floor, customer identities are metered by monthly activity, and the 30-day trial needs no card.
05
Frequently asked questions
Do we still need Entra ID after this?
Yes, and that is the design. Entra ID goes on holding the directory, evaluating conditional access and issuing the session your applications consume. SenseCrypt is the external identity provider it federates to for the authentication event, and the federation can be scoped to a single group while everything else stays as it is.
How does this help against adversary-in-the-middle phishing?
On the passkey path it helps directly: real FIDO2/WebAuthn passkeys (ES256) are bound to an origin, so a signature harvested through a relay proxy does not verify against your tenant. On the QR path the benefit differs in kind, because no password and no one-time code exists for a proxy to capture and reuse. The claim names the path rather than the platform.
What is stored on the SenseCrypt server?
IdP retains quantum-safe, sealed, biometric-free, disposable face tokens and their verifier challenges. Standard OIDC/SAML account records, device public keys, sessions, logs and encrypted tenant signing keys also persist. No face images or templates are retained in the documented phone flow. Licensed on-premises Webcam processes captures inside the customer deployment.
Does anything need to be installed on user laptops?
No. The device being signed in to runs a browser and needs no enrollment, no agent and no extension. The companion app lives on the user's enrolled phone, and on the two mobile app methods that phone is where liveness and matching happen. A webcam method that removes the second device is offered to enterprise customers on a trusted network through sales@seventhsense.ai. This licensed on-premises method processes captures inside the customer deployment and does not add an enrolled-phone possession factor.
Can we keep users and groups in sync?
Yes, through SCIM 2.0 (RFC 7644). Provisioning and deprovisioning are automated, so an account closed in your source of truth does not survive in one system while disappearing from the other.
What happens when someone replaces their phone?
The new handset has to be bound again, and that requires a possession proof: a one-time PIN to the user's email, an SMS where a number is recorded against the account, or the CIBA email-possession check. Self-service face recovery is deliberately absent, because a recovery route accepting a face without a possession proof would become the cheapest way to attack the account. The replacement must also prove a new device key; the account remains bound to the enrolled person through biometric-free, disposable face tokens, and the live face check is still required at sign-in.