Why do APCER and BPCER both matter in identity verification?

Why both error rates are needed to judge an identity check

APCER and BPCER measure different failure modes, so neither number on its own tells you whether an identity check is good enough. A system can look strong against spoofing but still reject too many genuine users, or it can be smooth for legitimate users while letting attacks through. The useful question is not which rate is lower, but whether the balance matches the risk of the process.

That balance is why practitioners should treat APCER and BPCER as a paired view of performance. For biometric and other high-assurance checks, the control is only as trustworthy as its ability to resist attack without making normal access unusable.

In practice, the two rates also help distinguish product quality from threshold choice. A vendor may show a low spoof acceptance rate in a narrow test, but if that comes with an inflated rejection rate in production conditions, the control is not fit for purpose. The same is true in the other direction: a generous threshold can make the experience feel frictionless while quietly weakening the security barrier.

How the two rates trade security against usability

APCER is the attacker-facing measure: it shows how often a spoof or presentation attack is accepted as real. BPCER is the user-facing measure: it shows how often a genuine person is rejected. Together they describe the operating point of the check, which is what matters when the control is deployed into a real workflow with fraud pressure, support costs and user frustration.

That operating point is rarely neutral. Tightening the decision threshold usually improves resistance to spoofing, but it can also increase false rejects. Loosening it often improves convenience, but it can weaken protection against presentation attacks, deepfakes, injection attempts or other bypass techniques. The right setting depends on what failure hurts more in the specific journey.

For teams evaluating biometric evidence, the Biometric Liveness and PAD Guide is useful because it explains how APCER, BPCER and related measures fit into ISO/IEC 30107-3 testing and production tuning.

When the process is part of onboarding or account recovery, the business impact of a high BPCER can be as real as the security impact of a high APCER. A control that drives legitimate users into manual review, repeated retries or abandonment may be technically strong but operationally weak.

How practitioners should read test results and thresholds

APCER and BPCER only become decision-useful when you know the test conditions behind them. Lighting, sensors, capture channel, sample quality, attack type and user population all influence the result, so the headline rates should be read as evidence about a specific configuration rather than a universal property of the product.

That is why practitioners should ask whether the reported numbers reflect the same environment they plan to run in. Remote proofing, in-person capture, mobile camera capture and help-desk verification do not fail in the same way, and a rate that looks acceptable in one setting may be misleading in another.

The Identity Proofing and KYC Guide helps place those metrics in a broader assurance workflow, where liveness checks, document checks and fraud controls are evaluated together rather than as isolated scores.

Practitioners should also separate threshold tuning from risk acceptance. If the control is guarding a low-friction consumer journey, a modest BPCER increase may be tolerable to reduce spoof acceptance. If it is protecting high-value account recovery or regulated onboarding, the tolerance for APCER usually drops and the review process becomes part of the control design, not an afterthought.

Risk and Threat Considerations

When one metric is optimised at the expense of the other, the control can become brittle in exactly the way attackers or frustrated users can exploit. A low APCER with an unacceptable BPCER can drive workarounds, manual overrides and support escalation, while a low BPCER with a weak APCER can create a bypass path that looks secure on paper.

Failure mechanism: The decision threshold or test profile overweights one error type, so the control either admits spoofed attempts too often or rejects genuine users too often. In practice, that can hide fraud risk in a “good-looking” security score or create pressure to weaken the control operationally.

Impact: The organisation either absorbs avoidable fraud and account compromise risk, or it creates denial-of-service-like friction for legitimate users, higher support costs and more exception handling. Over time, either outcome reduces trust in the verification process and can push users or staff toward insecure bypass behaviour.

Practitioner Guidance

What to verify: Check the APCER and BPCER numbers under the same capture conditions, population mix and journey step you will actually deploy. A lab result that does not match the real channel, device or attack surface should not drive production decisions.

Decision rule: If the process protects high-value access, treat spoof resistance and user rejection as joint control objectives, not competing metrics. If one error rate is missing from the vendor discussion, assume the evaluation is incomplete until both are measured and understood.

What good looks like: The control produces a balanced operating point where spoofing is hard enough to deter abuse and genuine users are not pushed into excessive retries or manual fallback. That is the sign of a verification process that is both secure and usable.

Practitioner takeaway: APCER and BPCER are complementary because identity verification fails in two different ways, and a control is only defensible when you understand both the attack bypass rate and the legitimate-user rejection rate.

Related resources from NHI Mgmt Group

• Why do hybrid identity architectures matter for cross-border verification?
• Why do human-in-the-loop approvals matter for identity verification?
• Why do pass rates matter so much in remote identity verification?
• Why does high-assurance identity verification matter for compliance teams?