By NHI Mgmt Group Editorial TeamBased on Yoti: “Italy’s new age verification regulation for online platforms” (October 31, 2025)

TL;DR: Italy’s AGCOM has approved rules that require pornographic websites to use robust age verification, including double blind checks that keep platforms and providers from seeing user identity data, according to Yoti. The governance issue is no longer whether age assurance exists, but whether verification architectures can prove adulthood without creating reusable identity trails.


At a glance

What this is: Italy’s new age verification rules require double blind checks that separate platform, provider, and user identity data.

Why it matters: This matters to identity and trust teams because age assurance controls now have to satisfy both verification strength and privacy minimisation, not just age gating.


Context

Age verification only works as a governance control when it proves a specific attribute, such as adulthood, without exposing more identity data than the decision needs. The problem in this article is not whether platforms can ask for age checks, but whether the architecture can confirm eligibility without turning each check into a reusable identity trail.

Italy’s regulator has pushed that question into the centre of compliance design for adult content access. For identity, privacy, and fraud teams, the interesting part is the double blind requirement: the platform should not see personal information, and the provider should not learn which site initiated the request. That is a stronger privacy posture than simple age gating and is more demanding than many legacy verification flows.

The article’s starting position is becoming less exceptional as regulators in the UK and France have already moved toward similar expectations. The practical shift is from one-off verification to governed, privacy-preserving assurance patterns that can withstand regulatory scrutiny.


Key questions

Q: How should organisations reduce identity exposure when verifying age or identity?

A: Use the minimum attributes required for the transaction and avoid exposing full document data when a single assertion will do. Attribute-level verification reduces fraud risk, limits unnecessary personal data sharing, and makes stolen identity documents less useful for downstream abuse.

Q: Why do double blind checks matter in age assurance programmes?

A: Double blind checks matter because they reduce the chance that an age-verification flow becomes a tracking mechanism. If the platform cannot see identity data and the provider cannot identify the requesting site, the system is closer to a one-time eligibility test and less likely to create a reusable identity trail.

Q: What breaks when age checks can be linked across sites or visits?

A: Linkable checks undermine privacy by turning a simple age gate into a behavioural record. That creates retention, correlation, and surveillance risks that can exceed the control objective. It also weakens trust, because the user may be sharing more identity context than the access decision requires.

Q: Who should be accountable for privacy controls in age verification services?

A: The relying platform remains accountable for the access decision, while the verification provider is accountable for limiting data exposure and maintaining separation of roles. Regulators will usually expect both parties to show that the design supports minimisation, independence, and auditability rather than data accumulation.


Technical breakdown

How double blind age checks separate identity from access decisions

Double blind age verification splits the trust chain so the relying platform learns only the outcome it needs, such as over 18, while the verification provider does not learn which site is making the request. That reduces identity exposure and limits correlation across transactions. The key technical point is that the age assertion must be sufficient for access control without exposing source identity data, consent metadata, or linkable session details. This is a privacy architecture problem as much as an authentication problem.

Practical implication: design age assurance so the relying party receives only an eligibility signal, not identity attributes or reusable identifiers.

Why anonymous age checks are harder than they sound

An age check becomes privacy-preserving only if each transaction is isolated enough to prevent cross-site linking. If the same token, wallet identifier, or metadata trail can be reused, the system starts to behave like persistent identity tracking rather than a one-time eligibility check. This is why policy language about anonymity must be matched by implementation choices such as unlinkable credentials, minimal disclosure, and strict separation between the requesting platform and the verification provider.

Practical implication: test age-assurance flows for linkability, not just for whether they return the right age result.

Provider independence and the risk of hidden conflicts

AGCOM’s rule that age verification providers should not be owned by adult operators addresses a governance issue, not just a commercial one. If the verifier is structurally tied to the content provider, there is a conflict between user privacy, regulatory neutrality, and business incentives to collect more data than necessary. Independence matters because the verifier sits at a control point where identity data, transaction context, and access decisions converge.

Practical implication: treat verifier ownership and control relationships as part of your age-assurance risk review, not as procurement detail.


NHI Mgmt Group analysis

Double blind age assurance is becoming a privacy architecture requirement, not a niche design preference. The article shows how regulators are moving beyond simple age-gating toward controls that minimise who can see what. For identity programmes, that means assurance must be designed around data separation, not just around proof of adulthood. Practitioners should expect more scrutiny of whether an age check leaks identity context into the access decision.

Persistent identifiers are the real governance risk in age verification flows. A system can satisfy the legal requirement to verify age and still fail privacy expectations if checks can be linked across sessions or sites. That creates a reusable identity trail that regulators are increasingly likely to view as excessive. Teams should assess whether their verification design preserves unlinkability at the protocol and policy level.

Provider independence now matters as much as verification strength. AGCOM’s stance reflects a wider governance pattern: the entity that asserts age should not have structural incentives to exploit the data path. That has implications for procurement, assurance reviews, and trust frameworks across digital identity. Practitioners should evaluate ownership, data access, and role separation before selecting an age-assurance model.

Age verification is converging with broader privacy-by-design expectations across identity and fraud programmes. This is not only an access-control issue for adult content; it is a signal about how regulators want sensitive assertions handled in future digital identity systems. The control pattern will be familiar to teams already dealing with minimisation, disclosure boundaries, and trust segregation. Practitioners should prepare for privacy-preserving verification to become the default expectation rather than a special case.

What this signals

Age-assurance programmes are moving toward attribute-only decisioning. That means teams should stop treating verification as a data collection problem and start treating it as a disclosure-minimisation problem. For identity architects, the design target is a durable control boundary between proof of adulthood and exposure of identity.

Double blind architectures create a governance test for every age-verification deployment. If the platform can see who the user is, or the provider can infer where the check came from, the model is already drifting away from privacy-preserving assurance. Teams should map that boundary explicitly in architecture, contracts, and compliance evidence.


For practitioners

  • Define the minimum age assertion Limit age verification responses to a simple over-18 or under-18 outcome and remove any unnecessary identity attributes from the transaction flow.
  • Test for linkability across checks Review whether tokens, device signals, or session metadata can be used to connect one age check to another across sites or visits.
  • Review verifier ownership and data boundaries Assess whether the age verification provider is structurally independent from the content operator and whether platform staff can access personal data.
  • Document privacy-preserving assurance controls Record how your age assurance model enforces double blind separation, minimal disclosure, and retention limits for compliance review.

Key takeaways

  • Age verification controls are shifting from simple age gating to privacy-preserving assurance that reveals only the minimum needed for access decisions.
  • The central governance risk is linkability, because reusable identity trails can emerge even when the age result itself is correct.
  • Teams should treat verifier independence, data minimisation, and unlinkability as core design requirements for age assurance programmes.

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, NIST SP 800-53 Rev 5 and OWASP ASVS set the technical controls, while GDPR defines the regulatory obligations.

FrameworkControl / ReferenceRelevance
NIST SP 800-63SP 800-63C — FederationAge assurance depends on privacy-preserving assertion delivery between provider and relying party.
Recommendation — Design age checks so the relying party receives only a minimal eligibility assertion and no unnecessary identity data.
GDPRArt.5 — Principles Relating to Processing of Personal DataThe article centres on minimisation, purpose limitation, and privacy-preserving verification of users.
Recommendation — Apply data minimisation and purpose limitation to ensure age checks disclose only what access control requires.
NIST CSF 2.0PR.AA-05 — Access Permissions, Entitlements and AuthorizationsAge verification is an access decision based on an identity attribute.
Recommendation — Bind age-based access decisions to explicit entitlements and document the authorization logic.
NIST SP 800-53 Rev 5AC-6 — Least PrivilegeDouble blind checks reflect the least-privilege principle for identity disclosure.
Recommendation — Limit who can see age-assurance data and ensure each party receives only the information it needs.
OWASP ASVSV14 — Data ProtectionThe control problem is preventing exposure of identity data during verification.
Recommendation — Verify that age-assurance flows protect identity data in transit, at rest, and in logs.

Key terms

  • Age Assurance: Age assurance is the set of controls used to determine whether a person can access content or services restricted by age. It can include document checks, biometrics, in-band verification and decision logging, but the governance requirement is the same: the organisation must be able to justify the outcome.
  • Double Blind Check: A double blind check is an age-verification flow in which the platform cannot see personal identity data and the verification provider cannot identify the requesting site. The design reduces correlation risk and helps keep the transaction limited to the age decision itself.
  • Unlinkability: Unlinkability is the property that separate sessions, sites, or interactions cannot be reliably tied back to the same user or browser instance. In privacy engineering, it depends on both storage boundaries and the elimination of side channels that expose stable state.
  • Attribute-Based Access Control: Attribute-Based Access Control is a policy model that grants or denies access using attributes such as user role, device state, location, and application context. It replaces purely static role assignment with a decision process that can adapt to current conditions, provided the underlying attributes are trustworthy and well-governed.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security practitioners design controls that reduce identity exposure across complex access flows.
NHIMG Editorial Note
Published by the NHIMG editorial team on July 31, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org