The Illusion of Reliability: What's Wrong with Identity Verification

Many remote identification solutions base their final verdict on indirect indicators: browser environment, network fingerprint, camera telemetry, and image statistics. While this data is useful for risk assessment, it provides a weak foundation for security if the system treats it as independent proof of authenticity. With the advancement of generative AI and media stream spoofing attacks, the distinction between a plausible and a verified document has become critical. This threat is addressed separately by NIST and ENISA.^[1][2]

What a Verification Process Should Actually Confirm

A robust process distinguishes between three independent questions:

1. Document authenticity: Does the presented physical medium or digital certificate correspond to a document issued by an authorized source?
2. Validity of the information: Are the details, the fact of issuance, and—when available—the current status of the document confirmed by a trusted source?
3. Ownership by the presenter: Is there sufficient reason to believe that the person undergoing verification is the same person to whom the document was issued?

A match of fields or the absence of signs of image manipulation addresses only part of the first question. NIST SP 800-63A-4 explicitly distinguishes between identity establishment, certificate validation, and confirmation of the presenter’s association with the claimed identity.^[1]

Eight Weaknesses in Common Approaches

1. Reliance on JavaScript and the browser environment

Some systems infer the device type and the “naturalness” of a session based on User-Agent, navigator.platformlanguage, time zone, touch input, screen parameters, Canvas/WebGL fingerprints, and other JavaScript data.

The problem lies in the source of this trust. The browser environment is controlled by the party initiating the request. Therefore, its claims cannot be equated with hardware-verified facts. JavaScript verification is useful for detecting inconsistencies and increasing the risk assessment, but it should not independently determine whether a device is genuine or whether identification is valid. OWASP specifically requires that significant conditions be re-verified on the server.^[3]

2. Static proxy/VPN lists and the p0f network fingerprint

IP reputation, lists of data centers, known VPNs, proxies, and anonymizers provide useful indicators but do not prove the origin of a document. Static lists do not cover all possible traffic routes, and the use or absence of a proxy does not in itself determine a user’s good faith.

p0f It analyzes passive characteristics of the TCP/IP stack. This is not a mechanism for authenticating a physical device. When operating through an application-level proxy, the network fingerprint may belong to an intermediate node rather than the original client. The p0f developers also recommend treating the result as an auxiliary indicator.^[4] Verification based solely on IP or p0f cannot reliably determine that a specific mobile phone is behind a request.

3. Recording camera parameters and telemetry across N frames

During recording, the service may collect the camera name (label), deviceId, groupId, resolution, frame rate, camera orientation, timestamps, and image sequence. Brightness (luminance), blur (blur), sharpness, contrast, exposure changes, glare, motion, inter-frame consistency, and frame drops. The availability of specific parameters depends on the browser, device, and permissions.^[5][6]

Such telemetry describes the received stream but does not, in and of itself, verify its physical source. If an attacker controls the incoming media, they may attempt to replicate the expected dynamics of the metrics. Capturing multiple frames, analyzing lighting, and querying for motion complicate the attack but do not replace verifying the signal’s origin and protecting against digital injection.^[2]

4. Static image analysis: heat maps, noise, and artifacts

Algorithms analyze anomaly maps (heat maps), Error Level Analysis, residual noise, signs of PRNU, JPEG quantization, DCT coefficients, splicing boundaries, local changes in sharpness, uneven lighting, character geometry, and matches with the document template.

These methods detect statistical deviations, not the fact of government issuance. The result depends on encoding, re-scanning, sensor quality, and the distribution of training data. The absence of noticeable artifacts does not prove authenticity, and a detected anomaly does not always indicate forgery. NIST requires that such algorithms be tested on genuine and adversarial samples and that false positives and false negatives be taken into account.^[2]

5. Formal Conformity of the MRZ, Barcode, and Printed Data

Comparison of the visual zone (VIZ) with the machine-readable zone (MRZ), as well as verification of check digits, dates, and the structure of two-dimensional codes, is essential. However, a correct check digit confirms the consistency of the data, not that a government agency ever issued a document with these details.

The reverse error is even more dangerous: the system detects a discrepancy between the MRZ and the front side but does not block a positive verdict. In NIST SP 800-63A-4, comparing the MRZ or barcode with the printed data is explicitly included in the requirements for automated optical verification.^[2]

6. “Dynamic” tokens without protection against reuse

nonce, a transaction ID, and a one-time challenge are only useful if the server verifies their validity, their association with the session and process stage, and whether they have been used previously. A randomly generated string does not constitute protection if it can be presented multiple times for different verifications.

Anti-replay protection must be provided by server-side logic and, where applicable, by cryptographically binding the result to a specific operation. OWASP considers token reuse and skipping process steps to be risks to the API’s business logic.^[7]

7. Liveness and Facial Recognition as a Replacement for Document Verification

Human presence verification (liveness / PAD) and comparing a face to a photograph address important but limited tasks. Even a successful biometric match does not establish that a document was actually issued or that the person whose face appears on the document is who they claim to be. Furthermore, PAD testing and the resilience of the entire chain to digital forgery are different types of assessments. ISO/IEC 30107-3:2023 is dedicated to PAD testing but does not claim to assess the security of the entire remote identification system.^[8]

8. Self-learning models without protection against data poisoning

A particular risk arises when a system automatically uses results from user uploads or poorly verified feedback to adjust model weights. Without trusted labeling, quarantine of new examples, version control, and independent validation, an attacker gains the ability to influence future decisions.

This class of threats is known as data poisoning and is discussed in detail by NIST in its taxonomy of attacks on machine learning systems.^[9]

Why the Problem Has Escalated in the Era of Generative AI

Protection based solely on the expected sequence of observations is vulnerable to replay: if the server receives a pre-generated stream, it cannot automatically treat the measured blur, luminance, motion, and delays as independent evidence of a real recording. Deterministic client-side checks, with sufficient control over the input data, can be replicated with high accuracy in a number of scenarios.

This does not mean that any algorithm can be bypassed with certainty or that all liveness mechanisms are useless. Security is strengthened by unpredictable checks, sensor authentication, server-side session binding, independent data sources, and cryptographic verification. However, none of these factors alone constitutes proof of a real identity. ENISA identifies attacks involving digital injection and fake media as significant threats to remote identification.^[10]

What We Found in Audits Conducted with Client Permission

As part of research conducted in coordination with system owners, our team identified the following classes of errors:

1. Trusting the User-Agent. Some implementations accepted claims of a mobile browser without sufficient independent verification of connection and device characteristics.
2. Reuse of security parameters. Parameters declared as “dynamic” were reused by the server without proper lifecycle control.
3. Live-learning poisoning. In one custom-built system, uploaded fake documents influenced the training loop, and the characteristics of such samples began to take precedence over previously established reference criteria.
4. Ignoring Inconsistencies. In one implementation, discrepancies between the machine-readable zone data and the visual portion of the document did not prevent a positive decision.

The responsible parties and manufacturers were notified of the identified shortcomings. The cases cited here are the results of our private audits, not a public statistical snapshot of the market: the names of the systems, the sample size, and the test materials are not disclosed here. They illustrate specific design errors and do not imply that all vendors have the same vulnerabilities.

The primary boundary of trust is the issuing source, not the image

A document may look perfect and be internally consistent, but it may contain details of a person who does not exist or whose identity has not been confirmed by an authorized source. Therefore, the verdict “no signs of tampering detected” cannot be equated with the verdict “identity established.”

Provided there is legal and technical access, the verification process must compare the document’s key attributes and status with the government registry, the issuing authority, or another authoritative or verifiably reliable source. For electronic passports, there is a separate cryptographic process: verification of the digital signature of the chip data and the chain of trust DSC → CSCA, as described by the ICAO. This confirms the origin and integrity of the signed data, but does not, in and of itself, replace verification of the document’s current status and its connection to the presenter.^[1][11]

If access to a reliable source is unavailable, the correct result is “authenticity of issuance or current status not confirmed,” rather than an unconditional “document is authentic.” In this case, the absence of a response from the registry does not prove forgery: the system must distinguish between a negative verification result and the inability to verify.

Our approach: verifying actual grounds for trust, not just indirect indicators

We evaluate a system not by the number of sensors, signatures, and algorithms in a presentation, but by what specific assertion each verification can prove and how it behaves under a targeted attack. For the client, we build a security model tailored to their documentation, jurisdiction, use case, and acceptable risk level.

• Independent layers of control. Browser, network, and visual indicators are considered as additional risk signals, not as standalone evidence.
• Secure verification process. Server-side stage control, one-time use, and challenge binding; detection of duplicates; and protection against digital stream tampering.
• Document origin verification. Validation of acceptable cryptographic evidence and integration with official or other authoritative sources where legally and technically feasible.
• Training loop protection. Separate storage of user uploads and reference annotations, controlled model updates, quality drift monitoring, and rollback capability.
• Measurable robustness. Assessment of false positives and false negatives (including DFAR/DFRR document analysis), testing for data stream substitution, repeats, conflicting fields, and new types of synthetic images.

For us, robust verification is not a promise of “100% protection,” but a reproducible procedure with clear sources of confidence, verifiable metrics, and an explicit distinction between the states “confirmed,” “unconfirmed,” and “inconsistency detected.”

Do you need protection against forged documents tailored to your specific needs?

There is no universal filter that is equally reliable for all documents and verification channels. If your goal is to reduce fraud involving fake documents, verify the robustness of your existing KYC process, or build a custom solution tailored to a specific jurisdiction and threat model, please contact us.

We’ll help you identify where your system relies on simulated signals, determine the necessary trust sources, and design a verification process whose robustness can be confirmed through technical testing—not just marketing promises.

Technical Sources

These sources confirm general technical properties, threat models, and standards. The specific results of our audits are described separately above.

1. NIST SP 800-63A-4 — Identity Proofing Overview. Separation of identity establishment, credential validation, and presenter verification; authoritative and reliable sources.
2. NIST SP 800-63A-4 — Identity Proofing Requirements. Optical analysis, MRZ, media stream substitution, attacks using generative AI, and testing requirements.
3. OWASP — Input Validation Cheat Sheet. Do not rely on client-side validation; server-side validation is mandatory.
4. p0f — Project documentation. Purpose of passive TCP/IP fingerprinting and limitations of the method.
5. MDN — MediaDevices.enumerateDevices(). List of media devices and restrictions on access to their metadata.
6. MDN — MediaStreamTrack.getSettings(). Available media stream parameters.
7. OWASP — REST Security Cheat Sheet. Protecting API state, step sequences, and tokens from reuse.
8. ISO/IEC 30107-3:2023. Test and reporting methods for biometric presentation attack detection (PAD).
9. NIST AI 100-2e2025 — Adversarial Machine Learning. Classification of attacks, including data and model poisoning.
10. ENISA — Remote ID Proofing: Good Practices (2024). Threats to remote identification, including presentation attacks and digital injection.
11. ICAO — ePassport Basics. Digital signatures in electronic passports and the DSC/CSCA chain of trust.