APCER shows how often spoofing is accepted, while BPCER shows how often real users are rejected. If you only optimise one, you can create a weak control that is either easy to bypass or too disruptive to use. Mature identity programmes assess both together because security and usability are part of the same decision.
Why This Matters for Security Teams
APCER and BPCER are not competing metrics. They describe different failure modes in the same identity verification control: one measures how often an attack presentation slips through, the other measures how often a legitimate claimant is blocked. For teams accountable for onboarding, authentication, fraud reduction, and customer experience, treating only one metric as “the” score creates blind spots that show up in production risk, support load, and abandonment.
This matters because identity verification is often used as a gate for high-impact actions such as account creation, recovery, step-up checks, or regulated transactions. A low APCER can still leave the programme fragile if BPCER is so high that users cannot complete the journey, which pushes exceptions into manual review or creates incentives for workarounds. That is especially important in sectors where identity assurance supports KYC, AML, or statutory identity schemes, where the control has to satisfy both security and operational tolerance. The eIDAS 2.0 — EU Digital Identity Framework is a good example of why assurance and usability cannot be separated.
In practice, many security teams discover the imbalance only after a spike in false rejects or a fraud ring has already adapted to a weak threshold.
How It Works in Practice
APCER and BPCER are best understood as paired measurements taken at a decision threshold. The threshold determines how strict the verifier is: tighten it, and more spoof attempts are rejected, but more genuine users may be turned away; loosen it, and more genuine users pass, but the attack surface widens. In other words, the question is not which metric is “better”, but where the acceptable tradeoff sits for the use case.
For identity teams, that means the decision should be calibrated to the business context rather than to a generic benchmark. A consumer login flow may tolerate a different balance than remote identity proofing for regulated onboarding. Current guidance suggests measuring APCER and BPCER by attack presentation class, device type, demographic segment where lawful and appropriate, and journey stage, because a single aggregate number can hide unstable performance.
- Use APCER to test resistance to spoofing, replay, presentation attacks, and other fraudulent inputs.
- Use BPCER to track friction, abandonment risk, and manual-review escalation caused by false rejects.
- Compare both metrics at the same operating point so threshold changes are visible as a tradeoff, not a win.
- Validate results in production-like conditions, because laboratory performance often overstates real-world resilience.
Where identity verification feeds KYC or high-assurance onboarding, the control should also be reviewed against policy, dispute handling, and recovery pathways so that false rejects do not become an ungoverned exception process. FATF guidance is relevant when identity proofing supports regulated customer due diligence, particularly in workflows that must be defensible to compliance reviewers.
These controls tend to break down when teams benchmark only against vendor-reported accuracy in controlled lab settings because real users, degraded cameras, and fraud adaptation change the operating point.
Common Variations and Edge Cases
Tighter identity verification often increases abandonment and manual review cost, requiring organisations to balance fraud resistance against user friction and operational capacity.
One common mistake is to treat APCER and BPCER as if a single target can be applied across every journey. Best practice is evolving, and there is no universal standard for this yet: a high-risk transaction may justify a stricter threshold than password reset, and a low-risk account recovery flow may prioritise BPCER more heavily to avoid locking out genuine users. The correct balance depends on the threat model, the downstream impact of a failure, and the availability of step-up controls.
Another edge case appears when the environment is asymmetric. For example, weak capture conditions, older devices, or remote enrolment can inflate BPCER without any change in spoof resistance, which makes the verifier look worse than it is. The opposite can happen when fraudsters use higher-quality attacks or synthetic identity artefacts, where APCER becomes the dominant concern. In both cases, a single pass/fail rate hides the real control problem.
In regulated identity ecosystems, the relationship between these metrics and legal obligations matters as much as the numbers themselves. Where identity evidence is used for trust decisions, teams should be able to explain why the chosen threshold is appropriate, how exceptions are handled, and how users can recover when the system rejects them. That is where assurance becomes governable rather than merely measurable.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST CSF 2.0 and NIST AI RMF set the technical controls, while PCI DSS v4.0 and DORA define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | IAL/AAL/FAL | Identity assurance levels frame acceptable false reject and spoof risk in verification. |
| NIST CSF 2.0 | PR.AC | Identity verification is an access control decision with security and usability tradeoffs. |
| PCI DSS v4.0 | 8 | Strong identity checks matter where verification gates access to payment environments. |
| DORA | Operational resilience depends on identity controls that work reliably under real load. | |
| NIST AI RMF | GOVERN | If AI supports identity checks, governance must cover model performance and failure modes. |
Use balanced verification metrics to reduce fraud without disrupting legitimate access to cardholder systems.
