Keystore node A
One service-held share
A stays hereHuman verification for critical actions
Prove it’s
really them.
Verify the person. Keep them involved in the approval. Connect BioTone’s multimodal checks and distributed signing design to the systems you already use.
Your biometrics. Your participation. Your control.
The key stays distributed.
The individual stays involved.
In BioTone’s three-of-three design, the two service-held shares cannot authorize a signature without the personal third share.
Three separate custody boundariesIllustrative 3-of-3 signing
Your device
Your personal third share
U stays with youPersonal participation includedKeystore node B
A second service-held share
B stays here✓
One verifiable signature
Partial signatures combine. The long-term key does not.
Explore the difference
Shares cooperate without reconstructing the complete long-term signing key. Your application validates the result and decides whether the requested action may proceed.
Signing-key custody and biometric-data storage are different boundaries. Temporary decryption keys and templates can be used in memory. Device integrity, policy, and authorized recovery remain part of the design.
Explore the security architecture →Start with the action you need to protect
Where does verification
matter to you?
Defense & federal
Verify the person behind mission access.
Explore the workflow →
Financial services
Put a verified person behind the approval.
Explore the workflow →
Healthcare
Verify access around the people delivering care.
Explore the workflow →
Technology & critical infrastructure
Make sensitive operations a deliberate decision.
Explore the workflow →Illustrative industry scenes, generated for this concept. No customer or agency endorsement implied.
Planning a physical capture point? Explore hardware options →
Multimodal verification
Choose the evidence
the action needs.
Combine selected identity matchers with presentation or pulse checks. Matching and liveness answer different questions.
Periocular
Features around the eye. Distinct from experimental iris recognition.
Palm
The texture and line structure of a contactless palm capture.
Voice
Speaker characteristics, paired with a spoken challenge.
Ear
Structure captured from a side-view image.
Concept illustrations. Current mobile matchers shown; availability depends on build, device, and policy.
Explore signals and liveness checks →Verification effort & policy
A quick check.
A deliberate step-up.
Different actions call for different evidence. Explore the wallet roadmap from a brief appearance check to the full ceremony.
Less interactionMore deliberate participation
Concept illustrationExperimental
A brief appearance check
A front-camera burst uses face or periocular evidence. It explores a lighter interaction for routine re-checks.
- Look toward the camera
- Evaluate appearance and presentation checks
- Request another check if evidence is insufficient
Explore returning to an already-open app.
The fast path does not unlock the wallet or complete a sign-in. Camera-specific presentation-attack performance still needs validation.
Adaptive selection · experimental
The action sets the requirement.
The wallet prototype chooses a next challenge using the action’s requirement, enrolled signals, presentation-check results, and paths already tried.
- Action + available enrollment
- Policy selects a check
- Evaluate evidence
- Step up when required
This is a qualitative roadmap, not an accuracy scale or measured speed comparison. Face and periocular share an appearance channel; pulse and lip-sync are not additional identity factors. Continuous-session work is experimental and does not establish continuous human presence. Experimental paths do not replace the current sign-in ceremony.
Plan the right verification flow for your pilot →Connect to the systems you use
Verification supplies evidence.
Your application decides.
Choose the processing path that fits your product and deployment requirements.
Illustrative processing flow · storage, custody, and recovery depend on the integration.
Phone boundary
Your phone
Guided capture
On-device matchingLocal biometric checks
Capture and matching share a device.
Verification result→
Your application boundary
Access policy
Validate the result
Check permission
Record the decision
Your system controls the action.
What crosses the boundary?Verification result
This mobile-broker pattern hands a verification result to your backend. Review enrollment storage, key custody, and any optional uploads for the selected build.
What should we confirm for this path?
Where the enrollment reference is stored, how the backend validates a result, and whether this build enables any uploads.
See the workflow
One sensitive file.
Three deliberate steps.
Connect an enrolled person to a specific request, then apply your access policy.
- 01 / Request
Name the resource.
Your application starts a verification flow for the requested file.
- 02 / Verify
Complete the checks.
The required checks complete and your backend validates the result.
- 03 / Decide
Apply the access rules.
The account has permission for this file. Your application allows access and records the decision.
File access allowed
This result applies to the requested file. Other resources still require their own permission checks.
The people behind BioTone
Leadership with
advisory perspective.
Roger W. Ach II and Benjamin Portman lead BioTone, with advisors bringing experience across cybersecurity, government, identity, science, and enterprise leadership.
Meet the leadership and advisors →What makes BioTone different?
BioTone combines multiple biometric checks with distributed signing authority. In its three-of-three design, two service-held shares cannot authorize a signature without the personal third share. Your application still validates the evidence and applies its own access policy.
Where is biometric data stored?
Mobile verification supports on-device templates. The hosted API performs server-side matching, while Edge and enterprise custody options have separate data flows. Confirm where captures, templates, encrypted material, and keys reside for your selected deployment.
How does integration with IAM work?
Use an authentication broker pattern: verification completes on mobile, your backend receives an asserted outcome, and you connect that to Microsoft Entra, OIDC/OAuth providers, or bespoke systems.
What sensors are required?
The mobile evaluation uses standard smartphone cameras and a microphone. Signal availability and capture quality vary by device. Sensor-constrained and physical-token deployments need a separate hardware review.
How long does a pilot take?
Pilots vary by IdP, policy, and integration depth. Expect a focused technical workshop plus staged rollout rather than a one-day toggle.
Turn one workflow into a measurable pilot
What action do
you need to protect?
Bring one requirement, an integration owner, and the devices people will use. Agree on the verification, custody, recovery, and acceptance criteria together.