Seventh Sense
Glossary

SenseCrypt
Technical library

Authentication

Passwordless authentication

Definition
Passwordless authentication verifies a user’s identity without asking for a password.

The proof shifts from something memorized to something a device holds or something a person is, which changes both what an attacker must obtain and where they must be standing to use it.

6 sectionsSeventh Sense / SenseCrypt
On this page

01

What passwordless authentication means

Nothing about the password is improved along the way: no rotation schedule, no minimum length, no better hashing algorithm. The credential is deleted from the design, and another kind of proof inherits its responsibilities.

The distinction that matters is the shape of the secret. A password is a shared secret, so two copies exist: one in a person's head and one on a server. Anything that reads either copy becomes the user. A device-bound passwordless credential, such as a passkey, is held in one place, is bound to one device, and is something the user could not hand over even if asked to. Link and code methods, covered below, remove the password without that property.

That last property is the reason the device-bound methods matter. Most credential theft today does not break cryptography. It asks a person for something, and the person complies. A method with nothing to hand over ends that conversation before it starts.

02

How a passwordless sign-in works

Under the branding, the device-bound methods share one structure. A server issues a fresh challenge, hardware the user controls produces an answer, and the server compares that answer against material recorded at enrollment. Whatever produced the answer stays where it was created. Magic links and one-time codes work differently: they deliver a readable value, which is why they are listed separately below.

Two variables separate one method from the next: what kind of proof gets produced, and how tightly that proof is bound. Together they account for almost all of the security difference between one passwordless product and another.

Authenticate with a device instead of a password

The factor becomes a registered object: a phone, a hardware key, a smart card. Losing one produces a support ticket rather than an incident, because no central store of possession exists for an attacker to exfiltrate in a single query.

Biometrics verify a human characteristic

A face check speaks to presence rather than possession. When a phone is taken while it is already unlocked, this is the one factor whose answer changes.

The network carries nothing reusable

The device signs the challenge or returns a single-use proof. What crosses the wire is the answer, not the material that produced it, so a captured message has no second life.

Binding determines the method's protection

A credential scoped to a single device, and frequently to a single site origin as well, cannot be replayed from an attacker's machine. Two products can both be passwordless and differ entirely on this point.

03

Why organizations move off passwords

The security case and the operations case point the same direction here, which is unusual in identity work. Verizon's Data Breach Investigations Report puts credentials in 28 percent of breaches in its 2026 edition, and the same body of research finds a median time-to-click on a phishing message of under sixty seconds. The password is not one weak link among many; it is the link most incidents are built around.

The operational return arrives first and is easier to measure. For most identity teams the reset queue is the single largest source of tickets, and it begins falling within weeks of the first cohort moving across rather than at the end of the program.

Remove reusable passwords from the attack surface

There is no password table to exfiltrate and no reused password to spray against a login endpoint. Somebody else's breach stops arriving on your doorstep as credential stuffing.

Recovery becomes a device question

Users have no secret to forget, so recovery shifts from verifying a memory to re-binding a device. Verifying a device is a procedure. Verifying a memory is a judgment call made under time pressure.

Reduce dependence on password habits

Complexity rules, rotation schedules and awareness training all ask people to compensate for the credential's design. A method that carries its own security property removes that dependency.

04

The common passwordless methods

Passwordless names a category, not an assurance level. Every method listed here removes the password, and they do not stop the same attacks. Buying by category instead of by property is how an organization ends up with a modern login screen and last year's incident report.

Choose against the specific attack the project exists to stop. Where losses come from phishing and account takeover, only origin-bound methods resist phishing outright; device-bound methods without origin binding remove the shared secret and raise the attacker's cost. Where the driver is support cost, the weaker methods still repay their deployment.

  • FIDO2 and passkeys: a key pair created for one relying party and unlocked locally on the authenticator.
  • On-device biometrics: a face or fingerprint check that releases a device-bound key.
  • Magic links: a single-use URL delivered to a registered email address.
  • One-time codes: a numeric value from an authenticator app, an email, or an SMS message.
  • Backchannel approval: the sign-in is confirmed on a separate enrolled device, away from the browser.

05

How SenseCrypt does passwordless

SenseCrypt is a passwordless identity provider from Seventh Sense. A user is enrolled from a photograph the organization already holds, and from then on signs in with a live face check, on their enrolled phone or, in enterprise deployments, by webcam on secure terminals. No password is set during enrollment, and none sits behind the face check. That is a decision rather than an omission: any fallback password reinstates the exact credential the architecture was built to eliminate, and it is the first thing an attacker looks for.

Three sign-in methods exist. Simple QR shows a code on the screen the user wants to open, and the face scan happens in the companion mobile app, where the liveness check and the comparison are both performed on the handset the user enrolled. The passkey method uses real FIDO2/WebAuthn passkeys (ES256) through a roaming authenticator app, and that is the phishing-resistant path, because WebAuthn binds each assertion to the calling site's origin. Simple Webcam is the deviceless mode: the face scan runs from a webcam and no phone is used. It is available to enterprise customers through sales@seventhsense.ai. The licensed on-premises webcam method processes captures inside the customer deployment and does not add an enrolled-phone possession factor. Run it on secure terminals: unsecured terminals expose webcam capture to injection attacks, such as virtual-camera or video-stream injection.

The companion app on the enrolled phone is part of the design in the two phone methods, not an optional extra. What carries no enrollment is the target: the browser, kiosk, desktop or shared terminal being signed in to holds no enrollment material, registers nothing, and can be a machine the user has never touched before.

Enrollment starts from a record you already hold

A photograph on file becomes the face enrollment, so users do not go through a separate face-registration ceremony. On the phone methods they still bind their phone once, with a one-time PIN, before their first sign-in.

The match runs on the phone in the phone methods

For Simple QR and the passkey path, capture, liveness and comparison all happen in the app on the enrolled device. Simple Webcam is the exception: it matches from a webcam inside the customer deployment, on secure terminals.

One token per ceremony, then it is spent

Each successful face ceremony consumes the current face token, produced by patent-pending face tokenization, and replaces it with a fresh one. A recorded exchange replayed later matches nothing.

No code is typed and none is read aloud

A routine sign-in requests no password or one-time code. One-time PINs are used only when a device is bound, at first enrollment or on replacement, never at routine sign-in. Delivery is by email, with an SMS copy where the account carries a mobile number.

06

Frequently asked questions

Is passwordless authentication more secure than a password?

Usually yes, because it removes the shared secret that phishing kits, credential stuffing and helpdesk resets all depend on. The size of the gain depends on the method: device-bound and origin-bound methods stop attacks that magic links and one-time codes do not.

Does passwordless always mean biometrics?

No. A passkey or a hardware security key requires no biometric factor at all. A biometric such as a face is one option among several, and it is the option that establishes which person is present rather than which device is held.

What if a user loses their enrolled phone?

Replacement-device enrollment requires email verification and a new device key; the enrolled face is still required at sign-in. Email verification is a one-time PIN sent to the recorded mailbox, with an SMS copy where a mobile number is held, or the CIBA email-possession proof. No password fallback exists and there is no self-service recovery by face alone, so the path is worth rehearsing with your support team before launch.

Does every device a user signs in from need to be enrolled?

No. On the phone methods only the user's own phone is enrolled. The browser, kiosk, desktop or shared terminal being signed in to holds no credential and needs no prior registration, which is what lets the method work on machines the user has never used before.

How does SenseCrypt handle a passwordless sign-in?

Users enroll from a photo on file and then sign in with a live face check. In the two phone methods, liveness and matching run on the user's own phone; Simple Webcam, the deviceless enterprise method, processes captures inside the customer deployment on secure terminals, because unsecured terminals expose webcam capture to injection attacks. IdP retains quantum-safe, sealed, biometric-free, disposable face tokens and their verifier challenges. Standard OIDC/SAML account records, device public keys, sessions (where the tenant enables session persistence), logs and encrypted tenant signing keys also persist. No face images or templates are retained in the documented phone flow.

Next step

The next level of detail depends on your stack, so the fastest route is a conversation.