Biometric software development is the work of turning a face, fingerprint, iris, voice or typing pattern into a reliable way to prove who someone is. Passwords are giving way to a glance at a phone or a touch on a sensor, and deepfakes have raised the stakes for anyone who verifies identity remotely. The money follows: The Business Research Company estimates the global biometrics market at about $59.7 billion in 2026, growing to roughly $103 billion by 2030. iProov reports that 72% of consumers worldwide prefer face biometrics to passwords for secure online processes.
For most companies, biometrics is not a standalone product but a feature inside a banking app, a patient portal, a workforce system or an onboarding flow. It has to fit existing identity providers, databases and audit processes, which is why we treat it as custom software development for identity and access systems rather than a plug-in. Good biometric software development services cover the whole chain: capture, liveness, matching, template security, consent, fallbacks and monitoring.
This guide explains how biometric systems work, how to choose between modalities, when a vendor SDK is enough, how to defend against spoofing and deepfakes, which laws apply in the US and EU, and what each project tier costs. If your product already processes camera input for other purposes, our guide to computer vision development covers the broader vision stack.
What is biometric software development?
Biometric software development is the design and engineering of systems that measure a physical or behavioural trait, convert it into a mathematical template and compare it against stored templates to make an identity decision. The output is never a simple yes or no from the sensor. It is a similarity score that your software turns into an accept, reject or step-up decision, based on thresholds you set for your risk level.
Physical traits include the face, fingerprints, iris, palm veins and voice. Behavioural traits include typing rhythm, swipe patterns, gait and how someone holds a phone. Professional biometric software development services combine these sensors and models with the parts that make a product usable and lawful: enrollment flows, consent screens, fallback login, admin tools and audit logs.
How a biometric system works
A biometric system works in six steps, and the same pipeline applies whether the trait is a face or a fingerprint:
- Capture. A camera, fingerprint sensor, microphone or touchscreen records a raw sample.
- Quality check. The software rejects blurry, dark, partial or badly positioned samples and asks the user to try again.
- Feature extraction. A model converts the sample into a compact set of numbers that describes the distinctive features, such as fingerprint minutiae or a face embedding.
- Template creation. At enrollment, those features are stored as a biometric template, ideally encrypted or kept on the device.
- Matching. At login, a matcher compares the new sample with one stored template or searches a gallery of many templates.
- Decision. The similarity score is compared with a threshold, combined with liveness and risk signals, and turned into accept, reject or step-up authentication.
Verification (1:1) vs identification (1:N)
Verification answers “is this person who they claim to be?” by comparing a sample with one enrolled template; identification answers “who is this person?” by searching a whole gallery. Unlocking a phone or approving a payment is 1:1 verification. Finding a returning customer in a database, or checking an applicant against a watchlist, is 1:N identification. The difference drives architecture, accuracy targets and legal risk: 1:N needs fast vector search, its error rates grow with gallery size, and regulators treat it far more strictly.
“Biometric” is also not a synonym for “facial recognition”. Facial recognition is one modality among several. A fingerprint login, a voice check in a call centre and behavioural analysis of typing are all biometric systems that never look at a face.
Accuracy metrics you must specify
Biometric accuracy is specified with a pair of error rates, not a single “accuracy” percentage, because lowering one error always raises the other. Put these metrics in your requirements and in any vendor contract:
| Metric | Plain-English meaning | Where it matters |
|---|---|---|
| FAR / FMR (false accept / false match rate) | How often an impostor is wrongly accepted | Payments, account recovery, physical access |
| FRR / FNMR (false reject / false non-match rate) | How often the genuine user is wrongly rejected | Conversion, support load, user frustration |
| EER (equal error rate) | The point where false accepts and false rejects are equal; a quick way to compare engines | Vendor and model benchmarking |
| APCER | Share of spoofing attacks that the liveness check wrongly accepts | Remote onboarding, high-value accounts |
| BPCER | Share of real users that the liveness check wrongly flags as attacks | Drop-off during onboarding |
APCER and BPCER come from ISO/IEC 30107-3, the standard for testing presentation attack detection. For face matching, the NIST Face Recognition Technology Evaluation (FRTE), formerly FRVT, publishes ongoing independent benchmarks you can use to shortlist engines.
Which biometric modalities should you build for?
Build for the modality your users already have hardware for and that matches your risk level: face for remote onboarding and mobile login, fingerprint for devices and physical access, and iris or palm vein where assurance must be very high. The comparison below is qualitative; real performance depends on the engine, sensors and population.
| Modality | Typical use | Hardware needed | Spoofing exposure | User friction | Best fit |
|---|---|---|---|---|---|
| Face | Mobile login, remote KYC, boarding | Any front camera; depth camera helps | High (photos, screens, masks, deepfakes) without strong liveness | Very low | Consumer apps, remote onboarding |
| Fingerprint | Device unlock, time and attendance, door access | Capacitive or optical sensor | Medium (silicone and gelatin fakes) | Low | Workforce, kiosks, devices |
| Iris | Border control, high-security access | Near-infrared camera | Low to medium | Medium | Government, critical facilities |
| Palm vein | Payments, hospital patient ID | Near-infrared palm scanner | Low (veins are under the skin) | Low | Healthcare, retail payment pilots |
| Voice | Call-centre authentication, voice assistants | Microphone | High (voice cloning, replay) | Very low | Phone channels, as a secondary factor |
| Behavioral | Continuous authentication, fraud detection | None beyond the device | Low to medium; hard to imitate at scale | None (passive) | Banking apps, session risk scoring |
Multimodal fusion combines two or more traits, such as face plus voice or face plus behavioural signals, so that an attacker has to defeat several checks at once and genuine users have a fallback when one trait fails. Fusion adds cost and complexity, so we usually reserve it for high-assurance flows such as account recovery, large payments or 1:N identification.
Biometric SDK vs custom biometric software development: which do you need?
Use a vendor SDK or cloud API for standard login and KYC flows; choose custom biometric software development when you need proprietary models, offline or on-device matching, unusual modality combinations, strict data residency, or when per-check fees stop scaling. Most products sit somewhere in between: a licensed matcher wrapped in custom capture, liveness, consent and integration code.
| Option | Time to market | Cost profile | Control over data | Accuracy tuning | Lock-in |
|---|---|---|---|---|---|
| Vendor SDK / on-device API (incl. Face ID, Touch ID, BiometricPrompt) | Fastest: weeks | Low build cost; licence or per-device fees | High when matching stays on the device | Limited to vendor settings | Medium |
| Cloud biometric API | Fast: weeks | Low upfront; per-verification fees grow with volume | Lower: samples leave your infrastructure | Limited | High |
| Custom build (own pipeline, licensed or own models) | Slower: months | Higher upfront; low marginal cost | Full: you choose where data lives | Full, on your own data | Low |
Custom biometric software development services make sense in four common situations: you operate where connectivity is unreliable and matching must run offline; regulators or customers require that biometric data never leaves a region or a device; you need a modality or fusion strategy no vendor offers; or verification volume is high enough that per-check fees exceed the cost of owning the stack. If none of these apply, start with an SDK and keep your own abstraction layer so you can swap vendors later.
How to develop biometric software in 7 steps
Developing biometric software takes seven steps, and the first three, defining assurance, choosing modalities and settling compliance, happen before any sample is collected. This is the sequence we follow on client projects.
1. Define the use case and assurance level
Start by writing down whether you need verification or identification, who the users are, and what a false accept would cost. Map the flow to an assurance level from NIST SP 800-63-4, the Digital Identity Guidelines finalised in 2025, which set requirements for identity proofing and authentication strength.
2. Choose modalities and a liveness strategy
Choose the modality your users can use with the hardware they already have, then decide how you will detect attacks. Passive liveness (no user action) gives the best conversion; active liveness (turn your head, read digits) adds friction but more signals. High-risk flows usually need both presentation attack detection and injection-attack detection.
3. Run a DPIA and map consent and retention
Run a data protection impact assessment and settle the legal basics before collecting a single sample. That means the consent text, the written retention schedule, the deletion process, who can access templates and which jurisdictions apply. Retrofitting consent after launch is where most biometric privacy lawsuits start.
4. Build or integrate the capture and matching engine
Build or integrate the capture flow, quality scoring, feature extraction and matcher. For mobile login this is often platform APIs plus a liveness SDK; for KYC or 1:N search it is a licensed or custom matcher behind your own API. Keep the matcher behind an internal interface so it can be replaced.
5. Protect templates
Protect templates as if they were permanent passwords, because they are. The safest option is to keep them on the device in a Secure Enclave or Trusted Execution Environment (TEE). When server-side storage is unavoidable, encrypt templates with keys held in an HSM or cloud KMS and use cancellable templates in the spirit of ISO/IEC 24745, so a leaked template can be revoked and re-issued.
6. Build fallback, audit and human-review paths
Every biometric flow needs a non-biometric fallback, such as a passkey or a one-time code, for users who cannot or will not enroll. Log every decision with scores and thresholds, and route borderline matches in high-stakes flows to trained reviewers rather than auto-rejecting them.
7. Test adversarially and monitor in production
Test the system the way attackers will: PAD testing to ISO/IEC 30107-3, injection attacks with virtual cameras and deepfakes, and accuracy testing across age, gender and skin-tone groups. After launch, monitor false-reject rates, attack attempts and drift. Fold all of this into your secure software development life cycle rather than treating it as a one-off audit.
What features does custom biometric software need?
Custom biometric software needs seven core features to be secure, usable and compliant; skipping any of them usually shows up later as fraud, support tickets or legal exposure.
- Enrollment with quality scoring that guides users to a good first capture, because a poor enrollment template causes false rejects for its whole life.
- Liveness and presentation attack detection, passive by default, with active challenges for high-risk actions.
- Template protection: on-device storage or encrypted, revocable server templates, and no raw images unless the law requires them.
- Consent and retention management: versioned consent records, per-jurisdiction notices and automatic deletion when the retention period ends.
- Fallback authentication with passkeys or OTP, so biometrics is never the only way in.
- Audit log and admin console showing who enrolled, every match decision and every manual override.
- Demographic performance monitoring that tracks error rates by group, so bias is caught in production rather than in a complaint.
Biometric technology stack in 2026
A 2026 biometric stack keeps as much as possible on the device, uses the platform's secure hardware, and reserves servers for 1:N search, orchestration and audit. For consumer products this sits inside a broader mobile app development effort.
| Layer | Typical choice | Why |
|---|---|---|
| On-device authentication | Apple LocalAuthentication (Face ID / Touch ID), Android BiometricPrompt | Templates never leave the Secure Enclave or TEE; the app only gets a yes or no |
| On-device models | Core ML, TensorFlow Lite, ONNX Runtime | Custom capture quality, liveness and matching without a network call |
| Passwordless login | FIDO2 / WebAuthn passkeys | Biometric unlock stays local; the server only sees a public-key signature |
| Model serving | Python and PyTorch services on GPU or CPU | Server-side matching, liveness checks and model updates |
| 1:N search | Vector search such as FAISS | Fast nearest-neighbour search across large template galleries |
| APIs and orchestration | Go, Java or .NET services | Integration with identity providers, KYC flows and core systems |
| Key management | HSM or cloud KMS | Template encryption keys never sit next to the data |
| Interchange formats | ISO/IEC 19794 and 39794 template formats | Interoperability with sensors, vendors and government systems |
Passkeys deserve special mention. With FIDO2 and WebAuthn, the face or fingerprint check happens entirely on the user's device and unlocks a private key. Your server never receives biometric data at all, which removes much of the storage and breach risk while still giving users a biometric experience.
How do you protect biometric systems from spoofing and deepfakes?
You protect biometric systems by layering certified presentation attack detection, injection-attack detection, device attestation and strict template security, because no single check stops every attack. The threat model has five main parts:
- Presentation attacks: printed photos, replayed videos on a screen, 3D masks and silicone or gelatin fingers held up to the sensor.
- Injection and virtual-camera attacks: the attacker bypasses the camera and feeds a synthetic video stream directly into the app or browser.
- Deepfake video and voice cloning: generated faces and voices built from a few public photos or recordings.
- Template theft: a breach of the template database, which cannot be fixed by a password reset.
- Replay: reusing a captured, previously valid biometric session or API request.
The matching defences are:
- Certified PAD tested by an accredited lab to ISO/IEC 30107-3.
- Injection-attack detection that checks the integrity of the camera feed and flags virtual cameras and emulators.
- Device attestation (Apple App Attest, Google Play Integrity) to confirm the request comes from a genuine app on a genuine device.
- Challenge-response prompts with random actions or light patterns that pre-recorded media cannot answer.
- Template encryption and revocable templates.
- Rate limiting and nonces to block brute force and replay.
- Step-up authentication for unusual behaviour or high-value actions.
Biometric privacy compliance: BIPA, CUBI, GDPR and the EU AI Act
Biometric data is among the most tightly regulated personal data in both the US and the EU, and the rules decide your architecture: where templates live, what consent you collect, how long you keep data and which uses are off-limits. Only Illinois, Texas and Washington have dedicated biometric privacy statutes, but about 20 more US states treat biometrics as sensitive data under their comprehensive privacy laws.
| Law | Jurisdiction | Key duty | Enforcement / penalty | What it means for your build |
|---|---|---|---|---|
| BIPA | Illinois | Public retention policy, informed written consent before collection, no sale of data | Private right of action; $1,000 (negligent) or $5,000 (intentional or reckless) per person since the 2024 amendment | Written consent flow and published retention schedule before the first capture |
| CUBI | Texas | Informed consent before capture for a commercial purpose, no sale, limited retention | Attorney General only; up to $25,000 per violation | Consent and deletion logic per Texas user |
| RCW 19.375 | Washington | Notice and consent before enrolling biometric identifiers for a commercial purpose | Attorney General | Notice and consent screens; check the My Health My Data Act too |
| HB 24-1130 (Colorado Privacy Act) | Colorado | Written biometric policy, retention and deletion rules, consent, including for employees; effective 1 July 2025 | Attorney General and district attorneys; no private right of action | Employee biometrics need the same rigour as customer data |
| CCPA / CPRA | California | Biometric data processed to identify a consumer is sensitive personal information | California Privacy Protection Agency and Attorney General | Notice at collection and the right to limit use |
| GDPR Art. 9 | EU / EEA | Biometric data used to uniquely identify a person is special-category data | Supervisory authorities | An Article 9(2) condition (usually explicit consent) and a DPIA |
| EU AI Act | EU | Bans certain biometric uses; remote biometric identification is high-risk | Market surveillance authorities | Risk classification and documentation for any identification feature |
The most important US change is the Illinois BIPA amendment (SB 2979), signed on 2 August 2024. Damages now accrue per person rather than per scan, which removes the threat of astronomical per-scan totals, and in April 2026 the Seventh Circuit held that the amendment applies retroactively to pending cases. BIPA still has a private right of action, so it remains the riskiest US biometric law for consumer and workforce products. In Texas, the TRAIGA law (HB 149) exempts most AI training and development from the CUBI consent rule from 1 January 2026, but commercial capture of biometric identifiers still needs consent.
EU AI Act timeline after the Digital Omnibus
The EU AI Act applies to biometrics in three stages. The Article 5 prohibitions have applied since 2 February 2025: untargeted scraping of facial images, emotion recognition in workplaces and schools, biometric categorisation that infers sensitive traits, and real-time remote biometric identification by law enforcement in public spaces, with narrow exceptions. The Article 50 transparency duties, including labelling of deepfakes, apply from 2 August 2026. The Digital Omnibus on AI, in force since 27 July 2026, moved the Annex III high-risk obligations, which cover remote biometric identification and biometric categorisation, from 2 August 2026 to 2 December 2027.
One-to-one biometric verification whose only purpose is to confirm that a person is who they claim to be generally falls outside the high-risk “remote biometric identification” category, but the boundary depends on the design, so get legal review. For a broader checklist, see our EU AI Act checklist for SaaS and our guide to GDPR for US founders. This section is general information, not legal advice.
How much does biometric software development cost in 2026?
Biometric software development costs about $35K–$80K for integrating a vendor SDK into an existing app and $200K–$450K for an enterprise multimodal platform, with proprietary model R&D above that. The table shows our planning ranges for 2026, based on YuSMP project experience; they are not market statistics.
| Project type | Our planning range, 2026 | Typical timeline |
|---|---|---|
| SDK or API integration into an existing app | $35K–$80K | 6–12 weeks |
| Custom mobile or web app with on-device matching and liveness | $90K–$200K | 4–7 months |
| Enterprise multimodal identity platform (1:N, admin, audit, integrations) | $200K–$450K | 6–12 months |
| Proprietary model R&D or own matcher | $450K+ | 9–18 months |
Cost drivers
The cost of custom biometric software development is driven less by screens and more by assurance, scale and compliance. The main drivers are:
- Number of modalities: each one adds capture, models, testing and fallback logic.
- 1:N gallery size: searching millions of templates needs vector infrastructure and careful threshold tuning.
- Liveness certification and third-party PAD testing by an accredited lab.
- Compliance work: DPIA, legal review per jurisdiction, consent UX and documentation.
- Per-verification vendor fees, which can dominate running costs at high volume.
- Hardware and sensors for kiosks, door readers or near-infrared capture.
- Maintenance and model retraining: as a rule of thumb we budget about 15–20% of the build cost per year.
For a broader view of how these numbers compare with other projects, see our breakdown of custom software development cost.
Biometric software use cases by industry
Biometric software is used wherever identity must be proven quickly and remotely, and each industry adds its own regulatory layer.
- Fintech and banking: remote KYC onboarding with document plus selfie match, and step-up authentication for large payments. Biometrics is one step in a wider compliance workflow, covered in our guide to KYC/AML software and our fintech software practice.
- Healthcare: patient identification to prevent record mix-ups and medical identity fraud, and clinician sign-off for e-prescribing. Our healthcare software team handles the HIPAA and GDPR overlap.
- Workforce: access control and time and attendance with fingerprints or faces. Employee biometrics fall under BIPA in Illinois and under Colorado's employee rules since July 2025.
- Travel and border: automated e-gates and seamless boarding where a face replaces the boarding pass at each checkpoint.
- Retail: pay-by-face and palm payment pilots at checkout, which need very low friction and very clear opt-in.
- Education: identity checks for online exams. Keep it to verification only: emotion recognition in education is banned under the EU AI Act, as explained in our guide to emotion detection software.
How to choose a custom biometric software development company
Choose a custom biometric software development company that can prove its systems survive attacks and audits, not just demos. Use this seven-point checklist when you compare any biometric software development company:
- Proven PAD-tested deployments, with lab reports you can read.
- Command of NIST and ISO metrics, and a written FAR/FRR test plan for your use case.
- Privacy-by-design and DPIA experience across US state laws and GDPR.
- Both on-device and server experience, so the architecture is chosen for you, not for their comfort zone.
- Bias testing across demographics, with per-group results.
- Clear IP and model ownership in the contract, including code, trained weights and test sets.
- Post-launch monitoring of error rates, attacks and drift, with agreed response times.
Strong custom biometric software development services also include an honest answer to “should we just use the platform APIs?”. A partner that always recommends a full custom build is optimising for its own invoice. For a general vendor checklist, read how to choose a software development company.
Biometric software trends for 2026
Five trends are shaping biometric software in 2026, and all of them push towards less stored biometric data and more attack resistance:
- Passkeys replacing passwords, with biometric unlock kept on the device and no biometric data on the server.
- Injection-attack and deepfake detection as standard in every remote onboarding flow, not an optional add-on.
- On-device and edge matching, which reduces latency, cost and breach exposure.
- Privacy-preserving templates, such as cancellable and encrypted templates that can be revoked after a breach.
- Multimodal and continuous authentication, combining face, voice and behavioural signals throughout a session instead of a single check at login.
FAQ
What is biometric software development?
Biometric software development is the engineering of systems that capture a physical or behavioural trait, such as a face, fingerprint, iris, voice or typing rhythm, convert it into a protected template and match it to verify or identify a person. A complete build covers capture and quality checks, liveness detection, matching, template protection, consent and retention management, fallback authentication and audit logging.
How much does custom biometric software development cost?
In YuSMP planning ranges for 2026, integrating a vendor biometric SDK into an existing app costs $35K–$80K over 6–12 weeks. A custom mobile or web app with on-device matching and liveness costs $90K–$200K over 4–7 months. An enterprise multimodal identity platform costs $200K–$450K over 6–12 months, and proprietary model R&D starts at around $450K. Per-check vendor fees and maintenance come on top.
How long does it take to build biometric authentication into an app?
Adding biometric login with a vendor SDK or the platform APIs (Face ID, Touch ID, Android BiometricPrompt) to an existing app usually takes 6–12 weeks, including consent screens, fallback login and testing. A custom app with its own matching, liveness and admin console takes 4–7 months. Enterprise platforms with 1:N search and integrations take 6–12 months, mostly because of compliance and adversarial testing.
Should I use a biometric SDK or build custom biometric software?
Use a vendor SDK or cloud API for standard login and KYC flows where speed matters and per-check fees are acceptable. Build custom when you need offline or on-device matching, strict data residency, an unusual combination of modalities, your own model tuning, or when per-verification fees no longer scale with volume. Many teams start with an SDK and replace parts later.
Is biometric data legal to collect under BIPA and GDPR?
Yes, with conditions. Illinois BIPA requires a written retention policy, informed written consent before collection and a ban on selling the data; damages are $1,000 or $5,000 per person after the 2024 amendment. GDPR treats biometric data used to identify people as special-category data under Article 9, which usually requires explicit consent and a data protection impact assessment. This is not legal advice.
How do biometric systems detect spoofing and deepfakes?
Biometric systems use presentation attack detection (PAD) to spot photos, masks, screens and fake fingers, tested to ISO/IEC 30107-3 with APCER and BPCER metrics. Against deepfakes and virtual cameras they add injection-attack detection, device attestation, challenge-response prompts and server-side checks of the capture pipeline. Rate limiting and step-up authentication limit the damage when an attack does get through.
What does a biometric software development company deliver?
A biometric software development company delivers the capture and enrollment flow, liveness detection, the matching engine or SDK integration, template protection, consent and retention management, fallback authentication, an admin console with audit logs, and test reports covering accuracy, spoofing and demographic performance. It should also hand over documentation for your DPIA and transfer ownership of code and any trained models.
Does the EU AI Act ban facial recognition?
No. The EU AI Act bans specific uses: untargeted scraping of facial images, emotion recognition in workplaces and schools, biometric categorisation that infers sensitive traits, and real-time remote biometric identification by police in public spaces, with narrow exceptions. Other remote biometric identification is high-risk, with duties applying from 2 December 2027 after the Digital Omnibus. One-to-one verification generally falls outside that category.
Last updated 8 October 2026. Sources: Paul Hastings, Illinois legislature passes major BIPA amendment; Constangy, BIPA amended to limit potential damages; Business Law Today, 7th Circuit holds BIPA damages remedy applies retroactively; American Bar Association, Texas data privacy; RecordingLaw, US biometric privacy laws; Venable, Colorado amends state privacy law; Davis Wright Tremaine, Colorado Privacy Act biometrics updates; Usercentrics, EU AI Act high-risk delay and Article 50; Secure Privacy, EU AI Act Digital Omnibus deadlines; GDPR, Regulation (EU) 2016/679; The Business Research Company, Biometrics global market report; iProov, biometric statistics; NIST SP 800-63-4. Cost ranges are YuSMP planning ranges. Not legal advice.
