How it works / Full Duplex Authentication^®

How does your user know it is really you?

An organization needs to authenticate its user. The person also needs a reason to trust the service asking for approval. Full Duplex Authentication makes that relationship work in both directions.

Explore the trust architecture Open the FDA whitepaper

Your service

501

Your enrolled app

501

A relationship both sides can check.

Explore the trust architecture.

Verifiable identity is the cornerstone of digital trust.

Full Duplex Authentication connects account authentication, the enrolled app’s server relationship and a deliberate human decision. The comparison is the visible part of that experience.

Requesting application
Starts the request and owns account access or the pending operation.
NoPass^™ authentication server
Handles the configured authentication exchange.
Enrolled app
Verifies its established authentication-server relationship.
The person
Checks the request they initiated or expected, then chooses.

Identity

Who is participating?

Authenticate the enrolled account with the configured factors.

Destination

Is this the connected service?

The enrolled app checks its authentication server; the integration connects that server to the application.

Intent

Is this the request I meant to approve?

A request can be expected without being initiated by the person, such as an agent-prepared action. The person still decides.

See what the person actually does.

The customer sign-in example uses the documented BigCommerce LoginFree^™ flow: scan the store’s QR code, compare the black picture and number on browser and phone, and accept in the browser. The customer reaches their account and the phone confirms success.

Read the illustrated customer guide

Try the authentication experience

Start with Sign in, then Scan, Compare and Result. Try the buttons, or use Tab and the arrow keys to explore.

Illustrative demo — no real sign-in or camera connection.

PasswordFree^® · BigCommerce LoginFree · interactive example

Start at the store.

An enrolled customer chooses PasswordFree to return to their account. Try the sign-in button in the store.

Your store

Welcome back.

Your orders. Your account.

PasswordFree

Enrolled appA familiar
way back.

Try the highlighted button or use the controls below.

Start at the store. An enrolled customer chooses PasswordFree to return to their account. Try the sign-in button in the store.

Scan the store’s QR code. Open the enrolled app and point the phone at the store’s QR code. Here, select Scan QR code in the phone’s viewfinder.

The same picture. The same number. Compare the black picture and code on the two screens. If they match, select Accept in the store. If anything looks wrong, select Decline.

You’re back in your account. The store opens the customer account and the phone shows a green confirmation.

Review your trust architecture

Trust also matters after sign-in.

A person may be signed in while a particular operation still needs their approval. NoPass can request a fresh confirmation on the phone at that point. The application holds the operation and uses the response in its execution policy.

Authentication establishes the account relationship. Application permissions decide what that account may do; an operation-approval step asks for the person’s decision when it matters.

Operation approval

An enrolled account is not identity proofing.

Read NIST digital identity guidance Integrations

Does FDA establish a person’s legal identity?

FDA authenticates an enrolled account in a configured service relationship. Initial identity proofing or KYC belongs to the organization’s separate process.

Does the picture replace the server checks?

No. The enrolled app’s authentication-server relationship and the integration are distinct from the comparison presented to the person.

We already use passkeys or MFA. What should we evaluate?

WebAuthn/FIDO2 supports phishing-resistant authentication through verifier-name binding. Start with an access or approval workflow you need to improve, and compare integration, user experience and recovery. FDA is not a replacement for every existing identity or authorization control.

1 / 6
Authentication was only half the problem.
Strong passwords do not settle every security decision. Legitimate users can still be misled into approving the wrong request.
- CISOReduce risk
- CIOEnable secure access
- VP FraudHelp stop authorized fraud
2 / 6
Mutual trust changes the game.
Full Duplex Authentication^® (FDA) brings mutual verification to digital interactions — authenticating the user and helping them verify the service and the intended action.
IDENTITYWho is participating?
DESTINATIONWho is asking?
INTENTIs this the action I intend to approve?
Mutual trust
3 / 6
Address sophisticated attacks, not just weak passwords.
Even strong users can be tricked into approving fraudulent requests. FDA helps reduce risk in supported flows:
- Phishing & social engineeringVerify the established service relationship
- MFA fatigue / push bombingDecline unexpected approval requests
- Man-in-the-middle attacksService verification, not just user verification
- Authorized fraudClearer context for informed decisions
Your Bank
Review and approve this payment?
Recipient
Acme Supplies Ltd
Amount
$12,480.00
Reference
INV-4487
ApproveDecline
4 / 6
Enable secure access and smooth experiences.
FDA supports strong security and simpler access, for both customers and your workforce.
PasswordFree^®for customers
Passwordless registration and sign-in
Trusted, seamless experiences
Stronger account protection
NoPass^™for workforce
Secure access to enterprise applications
Approval for sensitive operations
Human checkpoints for AI-prepared actions
5 / 6
Built for what’s next.
From human users to AI-prepared actions, FDA helps organizations manage trust, access and approval in a rapidly changing digital world.
- PeopleCustomers, employees and partners with trusted, passwordless access.
- AI agentsHuman approval for consequential actions prepared by AI.
- Your organizationLower risk. More confidence in every digital interaction.
6 / 6
Turn authentication into mutual trust.
Discover how Full Duplex Authentication^® can help you reduce risk and enable secure, seamless experiences for your customers, your workforce and the AI-powered future.
Explore your options TRUST BUILDS A BRIGHTER TOMORROW.
Read the whitepaper See approval example Talk to our team

Slide 1 / 6

One foundation for two product families.

One trust architecture. Two authentication experiences.

Full Duplex Authentication is the shared foundation. Choose around the people and systems you serve.

PasswordFree^®

Passwordless registration and sign-in for customer accounts, with integrations for supported stores and applications.

Explore customer access

NoPass^™

Passwordless workforce access and approval checkpoints for sensitive actions in your applications.

Explore NoPass

Full Duplex Authentication — the shared foundation

Inspect the implementation.

Examine the mechanism and the experience.

Read the patent, examine the published architecture and follow an implemented customer journey. A patent describes an invention; it is not a certification of a deployment.

Read US Patent 11,245,526 Full Duplex Authentication whitepaper Read the illustrated customer guide Open NoPass technical documentation

What if you did not start this request?

A matching picture is not a reason to approve an unexpected action. Keep the account closed, decline the request and use the service’s known support route.

Which request are you reviewing? I started this sign-in I did not start this request

Connected service

The service is waiting for the person’s decision.

Your enrolled app

Check the picture and number against the service you are using. A match alone does not grant permission.

This example shows a person choosing to decline; it does not simulate automatic attack detection.

What is Full Duplex Authentication?

Identité’s Full Duplex Authentication^® connects a configured authentication-server relationship with an enrolled app and a deliberate human decision. The app verifies its established server relationship; the integration connects that server to the requesting application. The visible picture and number comparison helps the person review the request, and does not replace the underlying server checks. See the existing architecture and demonstration for the actual flow and product-specific limits.

It does not certify a deployment, perform KYC, remove application vulnerabilities, prevent every compromised-device attack or make all fraud impossible. Trusted enrollment, certificate and key management, endpoint security, revocation, recovery and meaningful context remain necessary. A patent describes an invention; it is not deployment certification.

How are passkeys different?

What is mutual authentication? →

Evaluate the implementation and its boundaries

Start with the published architecture, technical resources and an identified product version. Confirm trusted enrollment, the app-to-authentication-server relationship, the application mapping, key lifecycle, revocation and supported recovery with the integration owner.

A patent establishes an invention, not a deployment certification. An authentication result is not continuous authorization, a guarantee against session theft or evidence that every business field was cryptographically bound. The application retains permissions, session policy and execution controls.

For a later human decision, use the approval integration checklist. Ask which controls are documented product behavior and which the application must implement.

Plan a phased enterprise migration

Evaluate authentication methods alongside enrollment, recovery, legacy dependencies and operational continuity. The seven-step enterprise guide connects architecture questions with a controlled migration plan.

Read the Enterprise Passwordless Migration Guide

Questions that help you plan a confident rollout

What happens if I lose the enrolled phone?

Start with the recovery process for your product and integration. Your organization should be able to revoke the old enrollment, restore access and review existing sessions. Confirm the recovery evidence and expected timing before rollout.

Can enrollment establish a legal identity?

Enrollment connects an account with the supported app relationship. Identity proofing or KYC is a separate process when your service requires it; define who may enroll and how that person is validated.

What if I decline, the request expires or the phone is unavailable?

Treat decline, expiry and an unavailable phone as distinct outcomes. Keep the operation on hold until application policy is satisfied, and give the person a clear route to retry or recover access. A delivered notification is not approval.

What if an action changes after approval or is submitted twice?

Keep the approval tied to the pending operation. Define which changed details require a fresh decision, how duplicate results are handled and how stale responses expire. Confirm the message and binding semantics with the integration owner.

Does FDA enforce application policy continuously?

The application owns permission and execution. Combine the approval checkpoint with the session controls, monitoring and policy reevaluation your organization needs.

Does this certify HIPAA, FedRAMP or AAL3 compliance?

Compliance depends on the complete deployment and the organization’s obligations. Assess enrollment, authenticators, recovery and operations against the applicable requirements; a product name or patent is not a certification.

Does FDA replace phishing-resistant passkeys?

Choose around the workflow you need. WebAuthn binds credentials to the relying party and origin; FDA adds its configured app/server relationship and human decision. Compare the actual deployment and recovery experience.

Which integrations can I plan around?

Use the current WordPress, BigCommerce or Shopify listing and setup guide to plan installation. Check the account model, multisite or multi-storefront needs, product version and recovery path with your integration team.

Reciprocal assurance in a configured flow

The enrolled user authenticates; the enrolled app checks its configured authentication-server relationship. The integration maps that relationship to the requesting application.

The person reviews the request; your application controls permissions and execution. That makes the checkpoint a practical part of your wider security architecture.

Reciprocal assurance in a configured flow

How does your user know it is really you?

Explore the trust architecture.