Platform

Verify an enrolled person before a sensitive action. BioTone combines biometric checks with a choice of mobile, hosted API, and enterprise integration paths, so you can design around your devices and data requirements.

Identity checks and liveness signals

Periocular, palm, voice, and ear matching provide identity evidence. Pulse and presentation checks add evidence of live participation. Your policy selects the required combination; supported checks depend on the device and integration. Iris recognition is experimental.

  • Periocular: Eye-region matching from camera capture; distinct from experimental iris recognition.
  • Palm: Texture and line structure from contactless palm imaging.
  • Voice: Compare the speaker’s voice while they read a fresh, time-limited digit prompt.
  • Ear: Cartilage geometry from profile capture.
  • Vitals (PPG): Use camera-based pulse detection as an additional liveness check when supported.
  • Presentation: Active liveness challenges (e.g., blink, motion) per session.

How it works

Enroll a person, verify a request, and connect the result to your access system.

Enroll on device

Users complete guided capture for the signals enabled in their deployment. Agree consent, storage, and deletion requirements before enrollment.

Verify under policy

A session applies the configured matching and liveness rules. Processing location depends on the mobile, API, or Edge integration you choose.

Integrate with IAM

Connect verification results to your identity provider or application backend. Validate the selected integration and its access policies in your pilot.

Abstract visualization of connected flows—representing tiered session checks and brokered handoff before an identity outcome is asserted.

Re-check when the action demands it

Experimental tiered verification explores quick checks for lower-risk moments and additional checks before sensitive actions. Evaluate interruption, reliability, and accessible fallback before enabling a repeated-verification workflow.

Define when a fresh check is needed, how users consent, and what happens if a check fails.

Security & trust →

Brokered authentication

Let someone verify on their enrolled phone while using a browser or kiosk. A QR code or deep link opens the request; your backend validates the returned result before allowing the action.

Developers → authentication broker

Deployment models

Start with hosted services, or discuss customer-operated components and self-hosting requirements. Confirm which deployment options are ready for your pilot, including connectivity and key custody.

Compare deployment modes → | Review data handling →

See it in your environment

See all use cases →

Bring one workflow and your identity-provider requirements. We will map the capture, verification, and access decision together.