Biometric versus telecom auth: the GDPR Article 9 tradeoff

Biometric versus telecom auth: the GDPR Article 9 tradeoff

The security argument for biometric authentication is familiar: a fingerprint, a face scan, or a voice print is something you are rather than something you remember, and therefore harder to steal. The argument has a regulatory counterpart that vendor marketing usually skips. Biometric data is classified as a special category of personal data under GDPR Article 9, and the compliance obligations that come with storing and processing biometric templates are substantially heavier than those for ordinary identifiers.

Telecom-based authentication sidesteps the Article 9 question because it does not involve biometric data at all. The identity anchor is the SIM and the operator's record of which SIM is registered against which MSISDN. The operator already holds this data under ePrivacy and telecom-regulation frameworks, and the authentication vendor does not acquire special-category data as part of providing the service.

This post explains the tradeoff at the level of both security posture and compliance overhead, drawing on the peer-reviewed literature on biometric effectiveness and the EU digital-identity framework.

What Article 9 actually requires

GDPR Article 9 prohibits the processing of special-category personal data by default. The categories include racial or ethnic origin, political opinions, religious beliefs, trade-union membership, genetic data, biometric data for the purpose of uniquely identifying a natural person, health data, and data concerning sexual orientation. The default prohibition is lifted only when one of a small list of legal bases applies, of which the most common in commercial contexts is explicit consent.

Biometric authentication processes biometric data specifically for unique identification, which puts it squarely within Article 9. Several practical compliance obligations follow.

Explicit consent: the data subject must consent to biometric processing specifically, not as part of a broader consent bundle. The consent must be informed, freely given, specific, and revocable. Bundling biometric consent with other consents (marketing, service provision, cookies) is a documented compliance failure.

Proportionality analysis: the use of biometric data must be proportionate to the purpose. A deployment that could achieve the same authentication security with non-biometric factors faces a proportionality challenge from data-protection authorities, since Article 9 is read as favouring the least-intrusive available means.

Data Protection Impact Assessment: processing biometric data at scale triggers a mandatory DPIA under Article 35, which must document the necessity of the processing, the risks to data subjects, and the mitigations applied. DPIAs for biometric deployments are frequently substantial documents and, in sensitive contexts, get reviewed by the supervisory authority.

Storage and security obligations: biometric templates cannot be changed when compromised the way a password can, so they require enhanced security measures. Template storage is often required to be encrypted at rest, with access logged and restricted, and retained only for the period strictly necessary.

Data-subject rights: requests for access, erasure, and portability under Articles 15 to 20 apply, with the practical complication that biometric templates are often stored in formats that do not lend themselves to portability or partial deletion.

Supervisory authority enforcement: enforcement actions against biometric-data controllers have been among the largest individual fines under GDPR, including the €20 million fine against Clearview AI in Italy and multiple actions against facial-recognition deployments in retail, policing, and workplace settings.

The eIDAS framework for electronic identification interacts with Article 9 by rewarding factor combinations over single-factor strong authenticators, which favours deployments that combine multiple non-biometric factors over deployments relying on a single biometric factor. The combination model produces high-assurance authentication without incurring Article 9 processing.

The security argument, measured

The peer-reviewed literature on biometric effectiveness is more nuanced than the marketing suggests.

Voice biometrics in banking contexts is effective when paired with machine learning and adaptive filtering, but accuracy is materially degraded by microphone variation and environmental noise without those enhancements. Baseline performance across diverse devices does not match what a lab benchmark reports. Production deployments have to account for the long tail of device configurations in the actual user population.

Face-plus-voice multimodal fusion achieves a lower equal-error-rate than either modality alone. FaceNet-plus-GMM with score-level fusion outperforms unimodal baselines, which establishes that combinations beat singletons in the biometric space too. Biometric-only authentication is not automatically stronger than multi-factor telecom authentication, and the comparison has to be done at the composition level rather than at the single-factor level.

Android-based multimodal biometric systems are implementable on commodity hardware, but RAM, CPU, and GPU constraints become the binding bottleneck on low-end devices. That is the hardware profile of most African fintech customers and a meaningful share of emerging-market fintech globally. A biometric authenticator that assumes smartphone-class hardware with a functional biometric sensor excludes a large share of the addressable user population.

The equal-error-rate biometric systems report is itself a function of the deployment. In production, false-accept rates and false-reject rates vary by demographic group, ambient conditions, and device. Marketing claims that describe biometrics as "unforgeable" are scientifically incorrect. The EER is non-zero, the false-reject rate varies by population, and biometric spoofing attacks have been documented across every biometric modality at this point.

What telecom authentication proves instead

Telecom-based authentication resolves the identity claim at the signalling layer. The mechanism is the Authentication and Key Agreement exchange the handset performs at network attach, which cryptographically proves the SIM holds a shared secret with the operator's Authentication Centre. The operator already holds the data needed to assert that the MSISDN on a given cellular session matches the claim the user is presenting. The authentication vendor accesses this data via an API rather than collecting new biometric data from the user.

The data-protection footprint is different in kind. The operator's subscriber record gets processed under Article 6 and the ePrivacy regime, not Article 9. No special-category processing is involved, no DPIA is triggered for this processing specifically, and the consent requirements are the ordinary service-provision ones rather than the explicit-biometric-consent regime.

The 2022 analysis of the eIDAS framework identifies the cross-border recognition pattern as rewarding qualified-attribute providers, of which licensed telecom operators are a plausible class. Telecom operators already carry out identity verification at SIM issuance under local regulator rules, which produces an attested attribute (the MSISDN-to-subscriber binding) that can be cited as the authentication anchor without re-collecting biometric data. For deployments in EU Member States, the eIDAS assurance level mapping supports this: a carrier-verified subscriber binding can map to eIDAS Substantial where the operator's KYC meets the framework's requirements.

The fusion analogue Tensormobile offers, without biometric involvement, combines silent authentication (network-layer MSISDN verification), device binding (the IMEI-SIM-registration tuple), and SIM-swap-recency signals. This three-signal composition achieves defence-in-depth properties similar to biometric-plus-factor designs without triggering Article 9 processing.

The practical cost of biometric compliance

For a product team evaluating authentication vendors, the Article 9 overhead shows up as concrete operational costs.

Legal review: every biometric deployment requires bespoke legal analysis in each jurisdiction of operation. Article 9 implementation varies by Member State (some layer stricter national rules on top of the GDPR base), and the analysis does not scale cleanly across markets. A biometric product launch in five EU countries can require five separate compliance workstreams.

DPIA authoring and review: a DPIA for a biometric deployment is typically a 40-to-80-page document covering the necessity analysis, risks, mitigations, consultation with data subjects or representatives, and the decision record. DPIAs have to be maintained and updated as the deployment changes. Supervisory authority consultations, when triggered, add months of process.

Template-storage infrastructure: biometric templates require encrypted storage, access logging, key management, retention controls, and revocation mechanisms. The infrastructure cost is not trivial, and the security requirements exceed those for ordinary personal data.

Data-subject rights handling: access and erasure requests for biometric data have a specific shape. A subject asking for the template itself, or asking for cryptographic proof of its deletion, creates operational workflows that most authentication vendors are still building out.

Supervisory authority liability exposure: the largest GDPR fines to date involve special-category data processing. A biometric deployment is a larger risk target than a telecom-authentication deployment for the same user base.

The total operational cost of a biometric authentication product is higher than the list price of the service. Procurement analyses that compare only the per-transaction cost miss the compliance overhead, and the compliance overhead frequently exceeds the per-transaction savings over multi-year deployments.

Telecom authentication does not eliminate compliance obligations. ePrivacy, national telecom-regulation frameworks, and ordinary GDPR requirements still apply. But the obligations are an order of magnitude lighter than Article 9 for the same functional authentication outcome, and the procurement comparison should include that difference rather than hide it.

Where biometrics is the right answer

Biometrics is the right choice for specific deployments where the factor composition, hardware environment, and compliance appetite all align.

High-assurance corporate or government deployments, where the user base is enrolled under a controlled process, the hardware is issued and managed, and the Article 9 compliance overhead is accepted as part of the security posture. In these deployments, biometric factors add a modality that telecom authentication cannot replicate, and the compliance cost is part of the design rather than a tax on it.

Device-bound authentication where the biometric never leaves the device, like FIDO2 and the passkey family, where the biometric releases a key stored locally and the authentication assertion is cryptographic. This pattern avoids Article 9 template storage on servers and is the architecture modern passwordless schemes adopt. It is biometric-locked device authentication rather than centralised-template biometric authentication.

Specific regulatory regimes that require biometric verification for specific transactions. Some national anti-money-laundering frameworks and some sectoral rules (eKYC in specific jurisdictions, national-ID-linked identity wallets) require a biometric factor as a matter of policy. In those cases, the question is not biometric versus telecom but how to satisfy the regulatory requirement with the best available implementation.

For broad commercial use cases like consumer fintech onboarding, account-recovery flows, or step-up authentication for medium-value transactions, the telecom-authentication route is frequently cleaner. Lower hardware dependencies, lower compliance overhead, equivalent security posture when composed with other factors.

How TensorAuth fits in

TensorAuth does not store biometric templates. The product surface is silent authentication, device binding against IMEI and EIR data, SIM-swap-recency signals, and the supporting fraud-signal family. None of these process special-category personal data under Article 9.

For an integrator, that means buying TensorAuth does not bring Article 9 processing obligations along with it. The operator's subscriber data stays at the operator. The API returns attestations and signals, not raw biometric material or personally identifiable template data.

For integrators who want to combine TensorAuth with an on-device biometric factor (FIDO2, platform passkey, device-local biometric release), the biometric data stays on the user's device and does not pass through Tensormobile infrastructure. The authentication decision composes a telecom-layer attestation with a device-layer biometric release, each layer processing data in its appropriate legal regime.

For integrators who need a centralised biometric authenticator, that is not part of Tensormobile's catalogue. The closest adjacent product is KYC Match, which attests to a match between a claimed name and birth date and the operator's subscriber record. KYC Match does not involve biometric data in any form and is not affected by Article 9.

The summary worth circulating in any procurement comparison: TensorAuth verifies identity at the network layer using data the operator already holds under telecom-regulation rules, without processing biometric special-category data under GDPR Article 9. For integrators where Article 9 is a meaningful cost line (any EU consumer-facing fintech, any service operating across multiple Member States, any deployment where compliance overhead is a first-order concern), telecom authentication often answers the question before the security comparison even begins.