Understand FAR, FRR, FMR, FNMR, and EER in biometrics, how the threshold affects security and usability, and how to specify and test performance in access control.
Check it out!
FAR, FRR, and EER are metrics used to evaluate biometric-system behavior against two opposite errors: accepting a person who should not be accepted and rejecting a legitimate person. They should not be read as isolated catalog numbers. In an access-control design, the result depends on the biometric modality, algorithm, capture quality, population, environment, database size, 1:1 or 1:N mode, and above all the threshold used to turn a similarity score into a decision.
The engineering decision is always a trade-off between security and usability. Reducing the probability of false acceptance generally increases the probability of false rejection; relaxing the threshold to reduce queues and denials may increase the risk of accepting impostors. The objective is therefore not to pursue the lowest FAR or the lowest FRR independently, but to establish an operating point compatible with the access risk and demonstrate it under conditions representative of the real environment.
FAR, FRR, and EER Measure Different Errors
In biometrics, comparison produces a similarity score between a presented sample and a biometric reference. That score is compared with a threshold. Depending on which side of the threshold the result falls, the system declares a match or a non-match.
The complete guide to access control treats biometrics as part of the system architecture; the performance metrics detailed here provide the quantitative layer needed to specify and accept that function.
| Metric | Represented error | Typical impact |
| FAR / FMR | impostor accepted as legitimate | security risk |
| FRR / FNMR | legitimate user rejected | operational and usability impact |
| EER | point at which the two rates are equal | summary performance comparison |
Terminology varies by source and context. NIST frequently uses false match rate (FMR) and false non-match rate (FNMR) to describe comparator performance. Commercial documents commonly use FAR and FRR. For engineering design, what matters is stating exactly which rate is being specified, how it was measured, and in which scenario.
FAR Represents Improper Acceptance
False Acceptance Rate is the rate of impostor attempts or non-genuine comparisons that the system declares as matches. In access control, this is normally the error most directly associated with violation of the security objective: a person without the authorized identity obtains a positive biometric result.
A small rate does not mean zero risk. If an application performs few comparisons per day, a given level may appear sufficient; in a large database or high-throughput point, the accumulated number of comparisons and the consequence of improper acceptance change the assessment. In addition, FAR measured with passive impostor attempts does not by itself represent resistance to deliberate presentation attacks.
FAR is not the same as spoofing resistance
A statistical false match occurs when two different samples receive a score above the threshold. A presentation attack is a separate adversarial problem at the capture layer. The first is a comparison phenomenon; the second requires dedicated PAD assessment.
For that reason, a system can show excellent FAR in a comparison test and still require separate evidence for presentation-attack detection. The dedicated article on liveness and anti-spoofing addresses that layer independently.
FRR Represents Improper Rejection of a Legitimate User
False Rejection Rate is the rate of genuine attempts rejected by the system. For the user, it is the classic case of presenting their own fingerprint or face and receiving a denial despite being properly enrolled.
High FRR creates queues, repeated attempts, longer passage times, operator intervention, and operational exceptions. In corporate environments, recurring false rejection can encourage insecure practices such as frequent manual release, use of alternative credentials, or neutralization of controls.
False rejection is not caused only by the algorithm. Enrollment quality, finger or face positioning, lighting, humidity, fingerprint wear, personal protective equipment, template aging, camera characteristics, distance, motion, and environmental conditions can all affect the result.
EER Is a Comparison Point, Not a Mandatory Operating Point
Equal Error Rate is the point at which false-match and false-non-match rates are equal. It is useful for comparing algorithms or configurations under the same methodology because it summarizes the relationship between the two error types at a single point.
However, a real system rarely should operate exactly at the EER. A data center, vault room, or critical area may require a more conservative threshold against false acceptance, accepting a higher probability of legitimate rejection. A high-throughput, lower-criticality environment may admit a different balance, provided the risk has been formally assessed.
EER is therefore a relative performance indicator. The operating point should arise from the security requirement, not from the mathematical crossing point for convenience.
The Threshold Turns a Score into a Decision
A biometric comparator does not usually produce a simple “same” or “different” result. It produces a score. The threshold is the limit that turns that score into an operational decision.
When the threshold is raised to require greater similarity, false matches tend to decrease and false non-matches tend to increase. Lowering it causes the opposite movement. This is why isolated claims such as “99.9% accuracy” are insufficient: without a threshold, population, scenario, and metric definition, the percentage does not adequately describe performance.
A biometric threshold is an engineering parameter: it should arise from access risk, the population, and expected operational behavior — not from a factory default.
FAR and FRR Form a Trade-Off Curve
As the threshold is swept across different values, different FMR/FNMR pairs emerge. This relationship can be represented by ROC, DET, or other performance curves. Reading them correctly allows an operating point to be selected according to risk.
From an engineering perspective, it is not enough to ask “what is the accuracy?” The relevant questions include:
- what FMR/FAR is achieved at the proposed threshold;
- what FNMR/FRR is achieved at the same threshold;
- which dataset was used in the evaluation;
- what were the gallery and population sizes;
- which capture conditions were used;
- which demographic groups were represented;
- whether the measurement refers to the algorithm or the complete system;
- whether the results are for 1:1 or 1:N.
These questions turn biometric procurement from brochure comparison into a verifiable technical specification.
FMR and FNMR Are Preferable When Methodology Must Be Rigorous
In standards and technical evaluations, FMR/FNMR terminology helps separate comparator performance from the failure rate of complete transactions. Depending on the procedure, an attempt may fail before comparison because of capture, quality, or acquisition problems.
In access-control design, this distinction is useful. A denial at the door may result from failure to detect a face, poor sample quality, inability to acquire a fingerprint, missing template, communication loss, access policy, or a false non-match by the algorithm. Treating every one of these cases as FRR hides the true cause.
The acceptance criterion should separate biometric matcher performance from end-to-end transaction success rate.
Sample Quality Changes Performance
Biometric systems compare representations extracted from physical samples. If capture contains too little discriminating detail, noise, or distortion, the genuine and impostor score distributions tend to move closer together and the error trade-off worsens.
For fingerprints, quality can be affected by dry or wet skin, abrasion, dirt, pressure, position, and sensor condition. For facial recognition, lighting, pose, expression, distance, focus, motion, resolution, occlusions, and camera geometry are relevant variables.
Brazil’s ANPD Technology Radar reinforces that biometric algorithms are subject to error and that accuracy depends on the method, technology, and population. This warning applies directly to engineering design: a laboratory result cannot automatically be transferred to every environment.
Poor Enrollment Contaminates Every Later Comparison
The reference template originates in the enrollment process. If enrollment uses an inadequate sample, poor quality, or an inconsistent procedure, every future authentication inherits that problem.
A biometric design must therefore specify the enrollment process, not only the terminal. It should define who may enroll users, how many samples are collected, how quality is checked, how exceptions are handled, how templates are protected, and how re-enrollment occurs when performance degrades.
Enrollment should be considered a form of continuous commissioning of identity. Users are not simply “imported” into a database; their biometric references need to be suitable for the expected performance level.
1:1 and 1:N Change the Statistical Problem
In 1:1 verification, the sample is compared with a reference associated with a claimed identity. In 1:N identification, the sample is compared against a gallery of many records to determine which identity has the best match.
The larger the gallery, the greater the number of comparisons performed per search and the more important it becomes to evaluate the risk of a false-positive identification. For this reason, 1:1 metrics should not be copied directly into a specification for a 1:N mechanism.
The distinction between verification and identification is addressed in greater depth in the dedicated article in this cluster because it affects architecture, performance, privacy, latency, and governance.
The Test Population Must Represent the Real Population
Biometric metrics depend on who was tested. A small, insufficiently diverse sample or a population unlike the real users can produce an optimistic estimate. Age, physical characteristics, skin tone, working conditions, use of personal protective equipment, and other variables may affect the behavior of particular modalities.
NIST recommends evaluating performance and demographic effects under conditions substantially similar to the operational environment and user base. Brazil’s ANPD also identifies risks of error, bias, and discriminatory effects.
This means the design should require sufficiently representative evidence and, where necessary, a pilot or local test. A vendor’s result can be a reference, but it does not replace validation in the population of interest.
Security and User Experience Are Coupled
An extremely restrictive threshold may appear secure on paper but create so many rejections that operations begin bypassing the system. Effective security considers the behavior induced by the control.
If legitimate users need three or four authentication attempts, queues grow. At a reception point, an operator may begin releasing access manually. In a mantrap, cycle time increases. In an industrial area, gloves or working conditions may make a modality impractical.
The correct approach is to establish a minimum security requirement and then optimize usability within that boundary. The threshold should not be reduced merely until complaints stop without measuring the effect on FMR/FAR.
The Impact of a False Match Depends on the Protected Asset
FMR does not have complete meaning without consequence. A false match at the entrance to a common office area does not have the same effect as improper acceptance in a server room, control center, laboratory, confidential archive, or process area.
A risk matrix can relate consequence, exposure, and authentication requirements. At higher-criticality points, biometrics can be combined with another factor, two-person rules, security zones, VMS, and supervision.
The access control system design should translate this analysis into a measurable performance requirement and test method.
MFA Reduces Dependence on a Single Biometric Decision
Biometrics can operate as the only factor or together with a card, PIN, or mobile credential. Where risk requires greater confidence, a multifactor architecture reduces dependence on a single probabilistic comparison.
MFA, however, does not automatically “fix” a poor matcher. High FRR still affects operations; inadequate enrollment still generates failures. The second factor should be part of a coherent architecture, not an excuse to ignore biometric performance.
The order of factors, timeout, exceptions, contingency, and offline behavior also need to be defined.
The Capture Environment Must Be Part of the Specification
The specification should include lighting, distance, height, position, physical protection, temperature, humidity, and exposure conditions whenever they affect the selected modality.
For facial recognition, camera position and backlight control may be more decisive than a small nominal difference between algorithms. For fingerprints, sensor ergonomics and the user population profile may dominate the experience.
The design criterion should not be “facial terminal with FAR X.” It should be “a system capable of meeting the comparison and transaction requirement under the defined operating conditions.”
Comparison Time Is Also a Requirement
Performance is not only about error. In high-throughput applications, the time between presentation, comparison, decision, and release affects capacity and queue formation. In 1:N, gallery size and processing infrastructure can increase latency.
The design should specify response-time percentiles or latency limits under representative load conditions. Averages hide peaks; a system that responds quickly in a laboratory can degrade when thousands of users are enrolled and several access points operate simultaneously.
Security, accuracy, and temporal performance need to be tested together.
Network Availability Changes the Comparison Mode
Terminals may perform comparison locally or depend on a server. In offline mode, the available database, thresholds, and rules need to remain consistent. An architecture that silently changes algorithms or datasets during contingency may behave differently precisely when a failure occurs.
The specification should define where the template resides, where comparison occurs, how policies are synchronized, and what happens when communication is lost. The same applies to firmware or algorithm updates: a change may alter scores and require new validation.
An Algorithm Update Can Change the Operating Point
A firmware or biometric-software upgrade may replace the algorithm, AI model, normalization, or preprocessing. Even if the interface remains the same, the score distribution can change.
Threshold parameters therefore should not be treated as permanent values. Change management needs to record version, configuration, justification, and retest results. If an update significantly changes the matcher, the system should be revalidated against the original requirements.
This discipline is especially relevant in enterprise systems with multiple sites, where a partial update can create inconsistent behavior between access points.
Operational Indicators Complement Laboratory Testing
After go-live, real operating metrics help detect degradation. Rates of repeated attempts, denials by user, failures by terminal, time of day, modality, and reason can reveal environmental or enrollment problems.
Operational logs, however, should not be interpreted directly as FAR because the system does not know how many attempts were impostor attempts and how many were genuine. They are transaction and experience indicators, useful for diagnostics and maintenance.
Mature governance separates benchmark metrics, acceptance metrics, and operational metrics.
How to Turn FAR and FRR into an Engineering Requirement
A robust specification should avoid percentages without context. At minimum, the requirement should state the modality, comparison mode, population, gallery size when applicable, threshold, test condition, and acceptance metric.
| Field | Example technical requirement |
| Modality | face, fingerprint, iris, or multimodal |
| Mode | 1:1 verification or 1:N identification |
| Metric | FMR/FAR and FNMR/FRR at the same threshold |
| Population | profile compatible with real users |
| Environment | defined lighting, distance, and conditions |
| Database | size representative of operation |
| Latency | limit measured under load |
| Evidence | test report + FAT/SAT logs |
It is not necessary to copy thresholds from an external reference into every application. NIST, for example, establishes values for its own digital-identity contexts; these are useful methodological references, not automatic substitutes for risk analysis in physical access control.
FAT Should Test the Matcher’s Logical Behavior
During FAT, the objective is to verify configuration, threshold, profiles, integrations, and controlled scenarios before final installation. Genuine samples, non-matching attempts, parameter changes, blocks, timeout conditions, and integration with the access decision should be tested.
FAT is also an opportunity to record the algorithm version, firmware, template format, and policy. Without this baseline, a future problem may be attributed to hardware when it actually originated from a configuration change.
SAT Must Reproduce the Real Environment
During SAT, real or representative users should test the system at the final location. Lighting, height, flow, distance, ergonomics, noise, and working conditions need to be similar to normal operation.
The article on commissioning access-control systems according to IEC 60839 provides the general verification structure. For biometrics, the test plan should add capture, comparison, and transaction metrics.
It is particularly important to record observed false non-matches, repeated-attempt requirements, and apparent causes. The objective is not merely to “prove it works,” but to discover the conditions in which it stops working.
Biometric acceptance needs to demonstrate performance in the real environment, with population, database size, lighting, load, and parameters representative of operation.
Acceptance Criteria Should Not Depend on a Commercial Demonstration
A demonstration with a few previously enrolled users under controlled conditions has limited value. Acceptance should use a script, sample, population, database, parameters, and evidence defined before testing.
The vendor should state which metric is being presented and how the number was obtained. Expressions such as “99.99% accuracy” or “recognition rate above 99%” are insufficient without a definition of false match, false non-match, threshold, and test protocol.
Independent engineering protects the owner from comparing numbers that are not technically comparable.
Biometrics Are Sensitive Personal Data
Processing templates, images, and other biometric data should consider Brazil’s LGPD. The ANPD classifies biometric data as sensitive personal data and highlights purpose, necessity, security, sharing, transparency, and error-related risks.
The performance requirement does not eliminate governance obligations. On the contrary: the larger the database and the greater the impact of automated decisions, the more important it becomes to document purpose, access, retention, and security controls.
The article Biometrics and Facial Recognition: Risks, LGPD, and Good Practices examines this legal and governance dimension in greater depth.
When biometrics connect identity, software, networks, and physical decisions, the design should treat performance, data protection, and integration as one verifiable architecture.
Demographic Metrics Need to Be Part of the Evaluation
An aggregate rate can hide unequal behavior between groups. If a system has significantly worse FNMR for part of the population, the operational and potentially discriminatory effect may be relevant even when the average appears adequate.
NIST includes demographic-impact evaluation in current digital-identity requirements. For access control, the methodological lesson is clear: whenever the modality or context justifies it, the test sample should make it possible to verify whether errors are being concentrated on a specific group.
This does not mean using a different threshold by group; it means requiring an algorithm and process that perform adequately across the real population.
EER Does Not Replace ROC or DET
Two algorithms can have similar EER values and behave differently in the low-FMR region that matters to a high-security application. Comparing only EER can therefore hide the relevant portion of the curve.
When the consequence of a false match is high, FNMR should be evaluated at the target FMR, or vice versa. This operating point is more useful than a single equilibrium number.
Acquisition Errors Need to Be Separated from Comparison Errors
If the camera does not detect a face, the sensor does not capture the fingerprint, or quality falls below the minimum level, there has not necessarily been a false non-match by the matcher. The failure may be in acquisition or sample quality.
Separating categories makes it possible to address the correct cause. Improving the algorithm does not fix a poorly installed sensor; lowering the threshold does not correct lighting; re-enrollment does not solve network latency.
In contracts, the test matrix should record the technical cause of each result rather than only “pass/fail.”
The Availability of an Alternative Also Influences the Threshold
In some environments, a false rejection can be resolved with a second attempt or an alternative factor at low operational cost. In others, every failure requires security intervention or stops the operation. This difference affects the acceptable trade-off between FMR and FNMR.
The architecture can provide controlled fallback: physical credential + PIN, operator validation, dual authentication, or an exception procedure. The fallback needs governance equivalent to the main flow so that it does not become the weakest path in the system.
Database Size Must Appear in the Design
In 1:N, operational gallery size is a design variable. Testing with 1,000 records and operating with 100,000 can change latency and the probability of a false-positive identification. The test database should be representative of the expected operational size.
Where growth is relevant, the design should provide capacity milestones and revalidation points. This applies both to terminals with local matching and to centralized servers.
There Is No Single Universal “Accuracy Rate”
The question “what is the biometric accuracy?” is incomplete. There are different modalities, algorithms, thresholds, populations, capture conditions, and comparison types. The same system may perform excellently in 1:1 and behave differently in a large-scale 1:N search.
A correct specification uses defined metrics, defined conditions, and reproducible test criteria. That is the basis for comparing proposals technically and accepting the system with traceability.
Checklist for Specifying Biometric Performance
- define the use case and protected asset;
- select the modality appropriate to the environment and population;
- state whether operation is 1:1 or 1:N;
- specify FMR/FAR and FNMR/FRR at the same threshold;
- use EER only as a comparative indicator, where applicable;
- record minimum enrollment and capture quality;
- define gallery size and test load;
- test representative environmental conditions;
- verify behavior across relevant population groups;
- separate acquisition, comparison, and policy failures;
- define fallback and exception handling;
- record algorithm, firmware, and configuration versions;
- perform FAT and SAT using an approved script;
- maintain operational indicators and change management.
Final Considerations
FAR, FRR, and EER become meaningful only when associated with a threshold, population, modality, scale, and operational context. In access-control engineering, error is not an abstract property of the algorithm: it becomes intrusion risk, queues, bypass, operating cost, and user experience.
The design should replace generic percentages with verifiable requirements. The logic is straightforward: define the risk, select the operating point, demonstrate performance in a representative scenario, and preserve traceability whenever the algorithm, environment, or population changes.
Technical references
[1] NIST. NISTIR 7298 Revision 1 — Glossary of Key Information Security Terms. Definitions of False Acceptance Rate and False Rejection Rate. Available at: https://nvlpubs.nist.gov/nistpubs/Legacy/IR/nistir7298r1.pdf
[2] NIST. A Tale of Two Errors: Measuring Biometric Algorithms. Gaithersburg: National Institute of Standards and Technology. Available at: https://www.nist.gov/blogs/taking-measure/tale-two-errors-measuring-biometric-algorithms
[3] NIST. Digital Identity Guidelines — SP 800-63B. Biometric Accuracy. Available at: https://pages.nist.gov/800-63-4/sp800-63b.html
[4] ANPD. Technology Radar No. 2: Biometrics and Facial Recognition. Brasília, 2024. Available at: https://www.gov.br/anpd/pt-br/centrais-de-conteudo/documentos-tecnicos-orientativos/radar-tecnologico-biometria-anpd.pdf/@@display-file/file
[5] SUPREMA. Access Control and Biometrics Course. Technical training material consulted in the A3A Engenharia internal knowledge base.
Frequently asked questions
FAR/FMR measures improper acceptance of a non-genuine comparison; FRR/FNMR measures improper rejection of a genuine comparison. Changing the threshold normally shifts the trade-off between the two rates.
Not by itself. Reducing FAR can increase FRR and make operation impractical. The appropriate operating point depends on risk, environment, population, and comparison mode.
It is the point at which false-match and false-non-match rates are equal. It is useful as a comparative indicator, but it does not mean the system should operate at that threshold.
No. FAR/FMR measures false matches in biometric comparisons. Presentation-attack resistance belongs to the separate PAD/liveness layer and needs its own evaluation.
No. Capture quality, population, lighting, ergonomics, database size, and operating conditions can change performance. The design should include representative validation during FAT and SAT.
Complementary technical materials
Key content on this topic
Related technical content
- Biometrics and Facial Recognition: risks, LGPD, and good practices for responsible use
- Facial-recognition turnstiles: flow, biometrics, and design criteria
