Biometric Liveness and Anti-Spoofing: PAD

Understand biometric liveness, anti-spoofing and PAD, metrics such as APCER/BPCER/IAPAR, and how to specify, test and accept the capability in access control systems.

Check it out!

Liveness and anti-spoofing are mechanisms used to reduce the risk of a biometric system accepting an artificial, replayed, or manipulated presentation as if it were a genuine characteristic from a person who is actually present. In standards terminology, the more precise concept is Presentation Attack Detection (PAD): detection of attacks performed at the capture device during presentation and acquisition of the biometric characteristic.

In access control, PAD does not replace FAR/FMR, FRR/FNMR, 1:1 verification, 1:N identification, multifactor authentication, authorization, or the physical barrier itself. It addresses a different threat. A matcher may distinguish genuine users from zero-effort impostors very effectively and still be vulnerable to a photograph, screen replay, mask, fingerprint replica, or another artifact presented to the sensor.

For that reason, specifying only “biometrics with liveness” is insufficient. A technically verifiable design must define the threat model, biometric modality, capture conditions, performance criteria, test evidence, failure behavior, and the method of verification during FAT, SAT, and commissioning. The objective is not to promise invulnerability, but to control a measurable risk without unduly degrading the experience of legitimate users.

Liveness, Anti-Spoofing, and PAD Are Not the Same Thing

“Liveness” is the most widespread commercial and operational term used to indicate that a sample appears to come from a live and present person. “Anti-spoofing” is a broader expression used for mechanisms intended to hinder or detect falsification. The ISO/IEC 30107 family uses Presentation Attack Detection because the standards problem is not limited to “proving life”: the focus is on detecting presentations made to the capture device with the intent of interfering with the biometric subsystem.

This distinction prevents an imprecise specification. An algorithm may look for eye movement, texture, depth, spectral response, tissue properties, or other indicators, but the design should not procure a particular technological “trick.” It should procure verifiable performance against presentation classes relevant to the risk.

Term	Typical use	Interpretation limitation
Liveness	Assess signals associated with a live presence	May suggest a narrower scope than the actual risk
Anti-spoofing	Prevent or detect falsification	Broad term that does not by itself define testing and acceptance methods
PAD	Detect presentation attacks at the capture point	Does not cover every threat to the biometric system

ISO/IEC 30107-1:2023 limits PAD to attacks that occur at the capture device during presentation and acquisition of the biometric characteristic. Data injection after the sensor, API compromise, template theft, database tampering, administrative-credential compromise, or controller bypass belong to other attack surfaces. A product with robust PAD therefore still depends on appropriate architecture, cybersecurity, and access policies.

The complete guide to access-control systems positions biometrics within the broader chain of identification, authentication, authorization, decision, and actuation. PAD is an additional layer in that chain, not a substitute for the others.

A presentation attack occurs at the capture point

A presentation attack occurs when a characteristic or artifact is presented to the sensor in order to induce an improper response. For facial systems, the threat class may include two- or three-dimensional presentations. For fingerprint systems, it may include materials capable of reproducing characteristics relevant to the sensor. Other modalities have their own attack surfaces.

The design requirement should not become a catalog of attack recipes. What matters is defining, at an appropriate level of detail, which presentation families are plausible for the asset, how critical the access is, and what evidence will demonstrate compatible resistance.

Position of PAD in the biometric access-control decision chain

The figure shows why PAD and matching should not be confused. A presentation may be bona fide and still not match the template; it may reproduce enough characteristics for the matcher yet be classified as an attack by PAD; or it may pass both layers and still be denied by the authorization policy.

Low FAR does not demonstrate resistance to presentation attacks

FMR/FAR and FNMR/FRR characterize comparison or biometric-decision errors under defined conditions. A presentation attack is an adversarial problem in which someone deliberately attempts to exploit the capture process. Equipment with excellent FMR for zero-effort impostor attempts is not automatically protected against artificial presentations.

Engineering documents should therefore separate at least three requirement families: capture quality, matching performance, and PAD performance. Combining everything into a phrase such as “high-accuracy biometrics with anti-spoofing” makes acceptance subjective.

Passive and active PAD are architectural choices

Solutions described as passive PAD attempt to classify the presentation without requiring a perceptible additional action from the user. Active approaches may introduce a challenge, interaction, or capture sequence. Neither approach is universally superior. The choice affects throughput, accessibility, training, ergonomics, rejection rates, and contingency operation.

The technique should be assessed as part of the system. In a low-throughput, high-criticality access point, an additional interaction may be acceptable. At an entrance with peak traffic, the same interaction may create queues, operational pressure, and exceptions that weaken the control itself.

Threat Model: What PAD Really Needs to Detect

The starting point should not be “which biometric reader should we buy?” but which threat needs to be controlled and what consequence follows if the mechanism fails. The same technology may be sufficient for an administrative area and inadequate for a critical room, laboratory, data center, industrial environment, or zone with enhanced segregation.

A useful threat model considers the value of the asset, attractiveness of the access, user profile, possibility of obtaining biometric material, public exposure of the characteristics, existing human supervision, presence of other credentials, and the consequence of an improper release.

The risk classification should then be converted into verifiable requirements in the access-control functional matrix: modality, authentication mode, PAD requirement, additional factors, attempt policy, failure behavior, event logging, and test criteria by access point or point class.

A printed photo is only the most obvious attack

Restricting the test to a single printed photograph can create a false sense of security. The assessment needs to consider representative presentation classes compatible with the modality, capture technique, and threat scenario. ISO/IEC 30107-3:2023 structures testing and reporting principles precisely to prevent a one-off demonstration from being mistaken for a broad characterization of performance.

This also means that the specification should avoid absolute statements such as “immune to photos, videos, and masks.” Results depend on the presentation attack instrument, fabrication quality, environmental conditions, position, distance, sensor, algorithm, software version, and decision parameters. Engineering should procure evidence, not adjectives.

A deepfake may or may not be a presentation attack

Deepfake is not synonymous with presentation attack. If synthetic content is physically presented or displayed on a screen to the capture sensor, it may participate in an adversarial presentation. If it is injected directly into a digital stream after capture, the threat is no longer in the same PAD domain defined by ISO/IEC 30107.

The design consequence is important: requiring PAD while ignoring channel integrity, device authentication, API protection, and server hardening leaves open an attack surface that the biometric mechanism was not designed to address.

1:1 and 1:N change the consequence of a bypass

In 1:1 verification, the system compares the presented sample with a claimed or previously selected identity. In 1:N identification, it searches for a match within a candidate database. The two architectures change risk, processing time, aggregate match probability, and the consequences of a bypass.

The dedicated article on 1:1 vs. 1:N biometrics examines this distinction in greater depth. For PAD, the rule is straightforward: presentation protection must be analyzed together with the comparison mode that follows it.

MFA reduces dependence on a single layer

Where criticality requires greater robustness, biometrics can be combined with another factor, credential, or operational condition. Multifactor authentication does not make PAD unnecessary, but it reduces dependence on a single barrier. Likewise, strong PAD does not justify weakening authorization, anti-passback, dual custody, or physical segregation when those controls are part of the security concept.

A layered architecture is preferable to relying on a single proprietary “liveness” indicator. The residual risk of each layer should be understood and combined with the others.

PAD Metrics: APCER, BPCER, IAPAR, and Legitimate-User Performance

Laboratory metrics are useful only when they correspond to the product, version, configuration, and conditions relevant to the project. A technical review can identify gaps between declared performance and what is actually specified for the design.

Independent validation is especially useful before freezing requirements, approving equivalencies, or accepting threshold changes.

Engineering Design Review

PAD introduces its own error matrix. A system may aggressively reject attacks while also rejecting legitimate people at an unacceptable frequency. It may also preserve an excellent user experience while allowing a relevant adversarial presentation class to pass. The design must address both sides.

APCER and BPCER characterize classification errors

In PAD evaluations, APCER is associated with the proportion of attack presentations incorrectly classified as bona fide for the evaluated class, while BPCER characterizes bona fide presentations incorrectly classified as attacks. They should not be confused with FMR/FNMR because they address a different decision stage.

Metric	Engineering question	Risk when high
APCER	Does PAD allow attack presentations from the tested class to pass?	Bypass of the detection layer
BPCER	Does PAD reject genuine users as if they were attacks?	Queues, exceptions, support burden, and operational bypass
FMR/FNMR	How does the matcher perform in biometric comparison?	False match or rejection of a legitimate user
IAPAR	What is the acceptance rate of attack presentations in the evaluated authentication context?	Adversarial success in the system under the adopted methodology

The technical value lies less in seeking a “magic number” and more in requiring methodology, population, conditions, presentation attack instruments, number of attempts, product version, configuration, and calculation method. Without that traceability, two percentages from different vendors may not be comparable.

NIST is a useful reference, not a universal limit for physical access control

NIST SP 800-63B-4, published in July 2025, addresses digital identity authentication in networked U.S. government systems. In that context, it requires PAD for facial recognition, recommends PAD for fingerprint and iris recognition, and indicates, for deployment testing, demonstration of IAPAR below 0.07.

These requirements are valuable as a contemporary engineering reference and demonstrate the separation between biometric performance and resistance to presentation attacks. However, they should not be copied automatically as a legal requirement or universal threshold for a Brazilian physical access-control system. Acceptance criteria should arise from risk analysis, the application, the technology, and the specific obligations of the project.

Matching and PAD thresholds require governance

Some solutions allow the sensitivity of matching, PAD, or both to be adjusted. Changing a threshold simply to “keep the turnstile moving” may reduce rejections while simultaneously changing risk. Critical parameters therefore need to be defined, documented, protected by administrative roles, and placed under change management.

The commissioning Data Book should record the approved configuration, versions, relevant parameters, test evidence, and acceptance baseline. Without a baseline, a later change may degrade the system without the organization being able to demonstrate when or why performance changed.

Physical and Operational Design: Sensor, Lighting, Flow, and Accessibility

When PAD is used in critical areas, the requirement must arise from the threat model, functional matrix, and actual conditions at each access point. Specifying only a “terminal with liveness” transfers security decisions to the vendor and makes acceptance subjective.

An independent design converts criticality, biometric modality, traffic flow, contingency behavior, and test criteria into verifiable requirements before procurement.

Access Control System Design

PAD performance does not exist independently of the environment. Camera, lens, effective resolution, illuminators, distance, angle, mounting height, scene background, solar exposure, reflections, temperature, dirt, humidity, vibration, and user position can affect capture and classification. In fingerprint systems, skin condition, contaminants, and sensor characteristics also affect the user experience.

The specification therefore needs to connect the security requirement to the physical design of the access point. Approving a terminal on a bench is not enough to assume identical behavior when installed near a glazed facade, outdoors, or in an industrial traffic flow.

PAD must be compatible with the expected throughput

Security that does not fit the operation tends to generate exceptions. If every attempt requires repetition, repositioning, or guard intervention, queues at peak times can lead to doors being held open, third-party authentication, creation of shortcuts, or migration to a less secure mode.

The design should establish reference throughput, expected transaction time, retry rate, failure handling, and procedures for users who cannot complete the flow. These criteria need to be tested with a representative population, not only with the technical team that installed the system.

Accessibility is part of the acceptance criteria

Equipment height, capture field, required approach distance, gestures, reaction time, and interface instructions can create barriers for certain users. A biometric design needs to provide operational alternatives and authentication methods compatible with the environment and applicable accessibility requirements.

The alternative must not become an ungoverned bypass. If a person cannot use the primary modality, the alternative flow still needs to preserve identification, authorization, traceability, and a level of control consistent with the risk.

Lighting and geometry must be tested on site

For facial recognition, lighting conditions may affect both matching and PAD. Backlighting, low illuminance, variable sunlight, or reflections can change features extracted by the sensor. If PAD depends on multiple optical channels, the physical architecture and operating window also need to be compatible.

SAT should reproduce foreseeable real-world conditions: different times of day, users with varied characteristics, permitted accessories, approach distances, and traffic conditions. The objective is not to “torture” the product with impossible scenarios, but to demonstrate that the system operates within the contracted operating envelope.

Enrollment, Templates, LGPD, and Cybersecurity

Enrollment and PAD address different problems, but they meet at a critical point. If the identity or initial template is enrolled incorrectly, the rest of the lifecycle may operate exactly as designed while still protecting a false identity or an improper association.

PAD during enrollment may be more critical than during later use

Enrollment should have governance over identity, operator, authorized workstation, sample quality, duplicate detection, approval, and audit trail. Where the threat model justifies it, PAD mechanisms during enrollment help reduce the risk of registering an adversarial presentation as the legitimate reference.

Revocation and re-enrollment also need to be defined. A biometric template is not a password whose physical characteristic can simply be changed; compromise and vendor migration require a lifecycle strategy.

Template protection remains essential

PAD operates before or during capture. After that, biometric representations are transmitted, processed, and may be stored. Encryption in transit and at rest, key segregation, administrative access control, hardening, logging, backup, retention, and secure disposal belong to another security layer and remain essential.

Where integrations with enterprise systems exist, the article on APIs, webhooks, and middleware in access control shows why service authentication, authorization, integrity, and event handling need to be designed beyond the biometric terminal.

LGPD requires governance proportional to the sensitivity of the data

Biometric data linked to a natural person are sensitive personal data under Brazil’s LGPD. This increases the need for a defined purpose, applicable legal basis, necessity, security, access control, coherent retention, and governance of processing. Brazil’s ANPD also highlights privacy, data-protection, and potential discriminatory risks associated with biometrics and facial recognition.

The decision to use biometrics therefore should not be made simply because the equipment offers the feature. The function must be justified within the access-control system, and collection and processing should be limited to what the use case requires.

Software- or AI-based PAD requires version management

A firmware, model, library, or backend update can change classification without changing the visible hardware. The contract and maintenance plan need to define how version changes will be evaluated, when regression testing is required, and how to return to the previous configuration if performance deteriorates.

PAD events should also be distinguished from simple matching failures. This granularity improves investigation, helps identify trends, and prevents repeated adversarial attempts from being interpreted merely as “poor biometrics.” Integration with VMS can enrich investigation, but does not by itself improve the algorithmic capability of PAD.

Offline operation and failures need explicit behavior

Some terminals perform matching and PAD locally; others depend on central services for part of the analysis. The design must clarify what happens when the network, server, license, or analysis service becomes unavailable. Continuing to grant access with degraded functionality can reduce security; blocking everything can compromise operational continuity or emergency routes.

This decision cannot remain hidden in the manufacturer’s default behavior. It should be specified by door class, aligned with the operating philosophy, and tested under contingency conditions.

How to Specify and Procure PAD Without Relying on Marketing Claims

In procurement, commercial names such as “AI liveness,” “3D anti-spoofing,” or “advanced detection” are not comparable by themselves. Technical bid evaluation should compare requirements, reports, versions, test conditions, deviations, and acceptance criteria.

Technical procurement support preserves traceability from specification through proposal, clarifications, supply, and testing.

Technical Procurement

A robust procurement process converts a need into a verifiable requirement. “Has liveness” does not define what will be accepted, what evidence will be presented, or how bidders will be compared. The specification should avoid both lock-in to a proprietary implementation and excessive generality that makes any marketing statement sufficient.

Engineering starts by defining the object: a biometric system for a given set of access points, with criticality classes, modalities, authentication policies, and integrations. Functional and performance requirements then follow, together with environmental conditions, prior evidence, supply tests, and acceptance criteria.

What the technical specification should require

Where applicable, the documentation should establish:

biometric modality and 1:1 or 1:N operating mode;
access points or classes of points where PAD is required;
threat model and presentation classes that guide the assessment;
required metrics and conditions under which they will be reported;
laboratory evidence or test reports applicable to the offered version;
minimum capture and installation conditions;
capacity, latency, throughput, and retry handling;
behavior during unavailability, PAD failure, and offline operation;
requirements for logs, time synchronization, event export, and integration;
requirements for template protection and communications security;
FAT, SAT, regression testing, and acceptance documentation;
update, maintenance, and change-management policy.

The list should be calibrated to risk. Not every access point requires the same level of evidence, but critical points should not depend on a checkbox that no one can test.

Certification and laboratory reports must be read critically

A declaration of conformity with ISO/IEC 30107-3 should not be interpreted as a generic certification of invulnerability. Scope, modality, product, version, configuration, evaluated attack classes, conditions, laboratory, metrics, and reported results need to be checked.

ISO/IEC 30107-3:2023 establishes principles and methods for evaluating and reporting PAD mechanisms; it does not standardize a specific algorithm or perform a general security assessment of the system. This boundary is essential in procurement: a valid report may answer only part of the engineering question.

Technical bid evaluation should compare evidence, not terminology

Two vendors may use the label “advanced liveness” for very different capabilities. Evaluation needs to place requirements, evidence, gaps, conditions, and deviations side by side. When data are missing, the result should be “not demonstrated” or “clarification required,” not approval by inference.

This reasoning connects to the technical requisition for procurement: PAD requirements need to reach the purchasing process in a format that allows proposals to be compared and traceability to be maintained through acceptance.

Recommended engineering scope

Engineering support for this topic may cover risk assessment, architecture definition, technical specification, functional matrix, review of vendor evidence, technical bid evaluation, FAT, SAT, commissioning, and final documentation. Boundaries should be explicit: who supplies test instruments and samples, who prepares the environment, who performs tests, who records evidence, and who has authority to accept deviations.

Deliverables may include a design-criteria memorandum, requirements matrix, technical specification, point matrix, test protocol, FAT/SAT report, punch list, configuration baseline, and Data Book. Measurement of the engineering service should be based on these products and milestones, not merely on meeting attendance or hours without verifiable results.

FAT, SAT, Commissioning, and Acceptance Criteria

PAD is demonstrated in the implemented system only when FAT, SAT, and field testing verify both rejection of the planned presentation classes and the behavior of bona fide users, integrations, and contingency scenarios.

Commissioning organizes protocols, evidence, nonconformities, retesting, and the configuration baseline so that acceptance is technical and traceable.

Engineering Commissioning

PAD stops being a promise only when it is tested in a traceable manner. The test plan should distinguish what can be validated in a controlled environment from what depends on the final installation. FAT and SAT have complementary roles.

FAT should demonstrate requirements before final mobilization

During FAT, the team can verify hardware and software versions, parameters, interfaces, logs, policies, planned presentation classes, behavior for bona fide attempts, and controlled failure scenarios. The protocol should clearly identify which results are objective and which observations require retesting on site.

The objective is not to reproduce every field risk in the laboratory, but to prevent basic problems from being discovered only after implementation. Evidence should include identification of the tested item, configuration, date, responsible personnel, results, and nonconformities.

SAT validates the final environment

SAT brings in geometry, lighting, position, network, controller, lock or turnstile, integration, user database, traffic flow, access policies, contingencies, and the real user experience. PAD that works on a test bench may behave differently at the site because of capture conditions.

The article on commissioning access-control systems according to IEC 60839 details the discipline of testing, evidence, and acceptance applied to the complete system.

Testing attacks without testing legitimate users gives an incomplete picture

A campaign focused only on blocking artificial presentations may hide high BPCER, repeated attempts, and operational degradation. The protocol should also measure legitimate-user success, transaction time, retries, and behavior across user groups and conditions relevant to the application.

If threshold adjustments are required, the change should be recorded and the relevant tests repeated. Accepting the system after “adjusting it until it works” without preserving the final configuration prevents future auditing.

Acceptance criteria should be defined before testing

The vendor should not discover on the day of SAT what the acceptance threshold will be. The protocol should define requirements, sampling, conditions, number of attempts where applicable, tolerances, handling of inconclusive results, nonconformity classification, and retest rules in advance.

It is also advisable to distinguish critical punch-list items that prevent release from minor items that can be addressed later with a defined deadline and responsibility.

Assisted operation consolidates the baseline

After go-live, an assisted-operation period may reveal situations that SAT did not capture: peak traffic, seasonal lighting, accessories, user-group behavior, intermittent unavailability, and exception procedures. The objective is not to reopen acceptance indefinitely, but to confirm stability and adjust parameters under governance.

Jornada de verificação de PAD da especificação ao aceite operacional

Operation, Maintenance, and Change

PAD security can degrade without an obvious physical failure. Firmware changes, terminal repositioning, lighting changes, camera replacement, improper cleaning, a new protective film, algorithm changes, or configuration changes can alter performance. Maintenance therefore needs to preserve the function, not merely verify that the equipment powers on.

The maintenance plan for access-control systems should include inspections and tests proportional to criticality, together with records of interventions and configuration changes.

Operational indicators help detect degradation

Repeated-attempt rates, bona fide rejections, PAD events, support tickets, passage times, and manual exceptions can reveal degradation before it becomes a permanent bypass. Trends should be analyzed by access point, period, and version while respecting applicable data-processing restrictions.

An increase in rejections after a software update, for example, should trigger technical investigation. Likewise, a sudden drop in PAD events does not necessarily indicate improvement: it may indicate that the feature was disabled, logging failed, or a parameter changed.

Physical maintenance can alter capture conditions

Repositioning a terminal, replacing a bracket, changing mounting height, or installing new lighting may seem like a simple intervention, but it can change the capture envelope. Critical points should have reinspection criteria and, where necessary, retesting of biometric functions after relevant changes.

Obsolescence should be addressed before support ends

PAD often depends on software, models, and libraries that evolve with threats and with the manufacturer’s platform. Lifecycle planning should address end of support, version compatibility, template migration, update availability, and a replacement strategy that preserves governance.

Design Checklist for Liveness and Anti-Spoofing

Before approving a biometric solution with PAD, the team should be able to answer the following questions with documented evidence.

What biometric modality and comparison mode are used: 1:1 or 1:N?
Which access points require PAD, and because of which risk?
What threat model defines the presentation classes to be evaluated?
Is the offered feature measurable PAD or merely a commercial “liveness” label?
Which metrics are reported, and under what test conditions?
Does the evidence correspond to the offered product, version, and configuration?
How does the system balance rejection of attacks and rejection of bona fide users?
Which environmental and geometric conditions limit performance?
What throughput must be maintained, and how are retries handled?
Is there an accessible and governed flow for users who cannot use the primary modality?
How are enrollment, revocation, and re-enrollment controlled?
How are templates and communications protected?
Which events are logged, and how are PAD, matching, and operational failures distinguished?
What happens during offline operation, server failure, or unavailability of the PAD function?
Do FAT and SAT have predefined protocols and acceptance criteria?
Is the final configuration recorded in the Data Book?
Do version updates require analysis and regression testing?
Do maintenance and operations use indicators to detect degradation?
Does the contract define responsibilities, evidence, retests, and punch-list closure?
Is there an authentication alternative consistent with the risk for legitimate exceptions?

If several answers depend on “we will decide during installation,” the risk has not yet been converted into an engineering requirement. The best time to close that gap is before procurement and implementation.

Final Considerations

Liveness and anti-spoofing should be treated as a Presentation Attack Detection problem, not as a product checkbox. The objective is to reduce the risk of an artificial presentation being treated as bona fide without making legitimate users a constant operational exception.

Engineering should define the threat model, metrics, operating conditions, failure behavior, evidence, and acceptance criteria, and then verify those requirements through FAT, SAT, commissioning, and assisted operation. The ISO/IEC 30107 family provides the conceptual and testing framework for PAD, while references such as NIST SP 800-63B-4 show how presentation-attack metrics can be incorporated into authentication policies within their intended context.

Strong PAD is an important layer, but it still depends on appropriate matching, data protection, cybersecurity, authorization, the physical barrier, maintenance, and change management to form a robust and auditable access-control system.

Technical references

[1] ISO. ISO/IEC 30107-1:2023 — Information technology — Biometric presentation attack detection — Part 1: Framework. Available at: https://www.iso.org/standard/83828.html.

[2] ISO. ISO/IEC 30107-3:2023 — Information technology — Biometric presentation attack detection — Part 3: Testing and reporting. Available at: https://www.iso.org/standard/79520.html.

[3] NIST. SP 800-63B-4 — Digital Identity Guidelines: Authentication and Authenticator Management. July 2025. Available at: https://csrc.nist.gov/pubs/sp/800/63/b/4/final.

[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. Sections on presentation-attack detection, multispectral technologies, and biometric authentication. Technical material consulted in the A3A Engenharia internal knowledge base.

Frequently asked questions

What is the difference between liveness, anti-spoofing, and PAD?

Liveness usually refers to mechanisms that assess signs associated with a live and present person. Anti-spoofing is a broader term for measures against falsification. PAD is the standards-based concept used by ISO/IEC 30107 for presentation-attack detection during biometric capture.

Does a low FAR or FMR demonstrate PAD performance?

No. FAR/FMR describe biometric comparison performance under defined conditions. PAD performance is a separate layer and requires its own evidence and evaluation.

Are APCER and BPCER the same metrics as FAR and FRR?

No. APCER and BPCER characterize PAD classification errors, while FAR/FMR and FRR/FNMR characterize biometric comparison or decision performance. The two layers should be specified separately.

Is PAD mandatory for every biometric access-control system?

There is no universal rule for every physical access-control application. The requirement should be derived from risk, the use case, and applicable standards or obligations.

How should a vendor claiming liveness capability be evaluated?

Review evidence tied to the offered product, version, and configuration, including methodology, scope, metrics, test conditions, and acceptance criteria.

Should SAT verify liveness and PAD in the final environment?

Yes, when PAD is part of the requirement. SAT should verify the function under the contracted installation and operating conditions, together with integrations and contingency behavior.

Does Brazil’s LGPD generally prohibit biometrics in access control?

No. Biometric data linked to a natural person are sensitive personal data, so processing requires an appropriate legal basis, purpose, necessity, security, and governance consistent with the LGPD and the use case.

Complementary technical materials