Add SenseCrypt to Ping Identity

Ping stays in the middle of the estate. Your service providers go on pointing at Ping, Ping goes on minting the sessions they read, and the connections, policies and reporting accumulated there are left alone. SenseCrypt joins at the top of that chain as an upstream identity provider.

What SenseCrypt assumes is the proof. On the mobile app methods the user faces the camera on the phone bound to them at enrollment, liveness and matching complete there, and Ping receives a signed token or assertion to map onto the record it already keeps. Upstream federation over OpenID Connect and SAML 2.0 has been standard Ping functionality for years, which is why this is a connection to configure rather than a component to run.

It is therefore a cheap experiment. Those connections are configured one at a time, so a single application or a single population can be moved and watched before anything else is touched.

Trust needs exactly two things from the SenseCrypt side: somewhere to send the user, and a way to check that the answer is authentic. Both are published documents, so nothing secret travels between administrators and no certificate is pasted into an email.

The rest of the effort is claim mapping, and it repays care. Ping builds its own user record and its own session out of the attributes you choose to send. An identifier that shifts the moment somebody updates an email address becomes account drift, usually discovered months later during an audit.

No biometric data is part of this exchange at all. On the two mobile app methods the check completes on the phone, and the federation carries only a signed statement that it completed for a named enrolled user. A webcam method that avoids the second device is offered to enterprise customers on a trusted customer network; contact sales@seventhsense.ai. This licensed on-premises method processes captures inside the customer deployment and does not add an enrolled-phone possession factor.

Everything here happens inside two administration consoles, which keeps the risk of the project in configuration rather than in infrastructure, and configuration can be reversed the same afternoon it was applied.

Run the first sign in on a real handset using a test identity, then inspect the record Ping wrote for that user. Mapping errors appear at exactly that point and nowhere sooner, and one account is a far cheaper place to find them than four hundred.

1. Settle the protocol first: OpenID Connect or SAML 2.0 for the upstream link.
2. In the SenseCrypt console, create a relying party record for Ping.
3. In the Ping console, add SenseCrypt as an external identity provider.
4. Give Ping the discovery URL for OIDC, or hand it the metadata file for SAML 2.0.
5. Line the claims up with your Ping directory attributes.
6. Attach the new provider to one connection or one population, not to everything.
7. Enroll a test identity, sign in by face, then read back the record Ping created.

Policies, connections and reporting survive intact, while the front of the flow loses its shared secret. That is the case for putting SenseCrypt above Ping rather than replacing anything: the blast radius of the decision is one connection.

It also puts attention on the part of the lifecycle attackers actually use. The 2023 MGM Resorts incident is the reference case: attackers reached the IT help desk by telephone, impersonated an employee, and the reported impact was approximately $100M. A project that hardens the front door while leaving account recovery to a persuasive phone call has relocated the attack rather than removed it.

SenseCrypt is deliberate about that path. Self-service face recovery does not exist, because a recovery route accepting a face without a possession proof would become the cheapest way in. Re-binding a device requires a possession proof: a one-time PIN to email, an SMS if a mobile number is recorded, or the CIBA email-possession check. Your service desk still needs a documented way to be certain who is on the line. 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.