UK age checks rely on provider reliability, not new legal duties

At a glance

What this is: NHI Mgmt Group's analysis, drawing on OneID's blog post: The Data (Use and Access) Act 2025 creates a statutory basis for UK digital verification services, but age-check obligations still come from other regimes and the act mainly governs provider reliability.

Why it matters: Identity and compliance teams need to separate provider certification from legal obligation, because buying a certified verification service does not by itself satisfy age-check duties or sector-specific rules.

By the numbers:

• The DVS register listed 46 providers offering 64 certified services as at July 2026.

Context

The governance gap here is simple: a business can rely on a verification provider without understanding whether the law is creating a duty, a certification regime, or both. In UK age checks, those are different questions, and the Data (Use and Access) Act 2025 answers only the provider-reliability side.

The Act creates a statutory framework for digital verification services and a public register, but it does not itself force organisations to verify age. That distinction matters because compliance teams often treat a certified provider as if it automatically satisfied the underlying business obligation.

For teams designing age assurance flows, the first issue is not technology selection but legal scope. The relevant question is which regime creates the duty, which regime governs the provider, and where evidence of reliability actually comes from.

Key questions

Q: What is the difference between provider certification and legal age-check duty?

A: Provider certification shows that a verification service meets the statutory framework’s requirements, but it does not create the buyer’s legal obligation to check age. The duty comes from the regime that governs the service, such as the Online Safety Act or sector-specific rules. Teams should treat certification as evidence, not as a substitute for the underlying obligation.

Q: When should organisations trust a public register for age verification providers?

A: Use a public register when you need a checkable record of provider status, framework version, supplementary codes, certifying body, and expiry. It is useful for procurement and periodic review, but it only answers whether the provider is certified for a defined scope. It does not answer whether your service is required to run an age check in the first place.

Q: What should security and compliance teams verify before buying a digital verification service?

A: Teams should verify the exact legal duty, the provider’s certified scope, the version of the trust framework, and the expiry date of the certificate. They should also confirm whether the service is being used as evidence of reliability or as part of a broader legal obligation. That distinction prevents false compliance claims.

Q: Why do age assurance programmes fail in practice?

A: They usually fail when organisations treat age checks as a front-end feature instead of an evidence-based control. Weak boundary testing, poor audit records, and uneven demographic performance create the biggest gaps. If the organisation cannot explain how a decision was reached, it cannot defend the control.

Technical breakdown

What the statutory DVS framework does and does not change

Part 2 of the Data (Use and Access) Act 2025 gives the UK a legal structure for digital verification services, including a trust framework, supplementary codes, a register, an information gateway, and a trust mark. The important boundary is that this structure governs provider reliability, not the legal obligation to carry out an age check. In practice, that means a certified provider can support compliance evidence, but the Act itself does not create the age-check duty. The legal significance sits in the service-control layer, not in the customer obligation layer. See the UK GDPR and Data Protection Act 2018 Guide.

Practical implication: Separate the rule that governs a provider from the rule that creates the age-check obligation.

Why the public register matters for provider due diligence

The statutory register is the operational mechanism that makes certification checkable. It lets a buyer see whether a provider is registered, which framework version it is certified against, which supplementary codes apply, who certified it, and when the certificate expires. That turns marketing claims into evidence that can be tested field by field. It also means versioning matters, because a provider can be legitimate under one framework version while not yet entitled to use the newer trust mark or claims tied to it. See the UK Digital Verification Services Trust Framework Guide.

Practical implication: Use the register as a verification source for procurement, assurance, and periodic supplier review.

What the DVS trust mark actually signals

The trust mark is a signalling device, not a substitute for legal duty. Under the Act, only registered providers may use it, and even then entitlement is tied to the relevant certification state. The mark indicates that the provider sits within the statutory framework, but it does not make the buyer compliant with every downstream regime that may apply to age assurance. That distinction is easy to miss when vendor material compresses certification, assurance, and obligation into one claim.

Practical implication: Treat the trust mark as evidence of registered status, not as proof that the whole age-check process is compliant.

Threat narrative

Attacker objective: The objective is to exploit governance confusion so that a weak or mis-scoped age-check process is treated as compliant.

1. Entry begins when an organisation accepts a provider claim about age verification without checking the statutory status of the service, its version, or its certification scope.
2. Privilege escalation occurs when that assumption is treated as if it satisfied the organisation’s own age-check duty, even though the Act does not create that duty.
3. Impact is compliance drift: a business may believe it has covered age assurance when it has only verified provider reliability and missed the actual legal requirement.

Breaches seen in the wild

• Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.
• Meta AI Instagram Account Takeover: 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Certification is not obligation: The most common governance mistake is to collapse provider assurance and legal duty into one control. The Data (Use and Access) Act 2025 regulates digital verification services, but it does not require organisations to run age checks. That means compliance teams need to model the obligation source separately from the provider assurance source, or they will misstate what the control achieves.

Public registers change procurement, not policy ownership: A statutory register improves due diligence because the buyer can inspect certification status instead of relying on vendor claims. But procurement evidence is not governance ownership. The organisation still owns the decision about whether its service needs age assurance, and under which legal regime that decision sits.

Trust marks create a false sense of closure: A designated mark can make a provider look operationally complete when the real question is whether the downstream service is lawful. The trust mark tells you the provider is registered; it does not tell you whether the service’s age-check flow meets the duties imposed by the Online Safety Act or any sector rule.

Version control is part of compliance evidence: The framework version, certificate expiry, and supplementary codes are not administrative details. They define what a service is actually approved to do, and for which use cases. Buyers that ignore those fields are not buying assurance, they are buying ambiguity.

What this signals

Provider governance is becoming auditable: Public registers shift age assurance away from opaque vendor claims and toward inspectable certification data. That is useful for procurement and assurance, but only if organisations keep the provider’s certification status separate from the service’s legal obligation.

Version control will matter more than branding: As certification frameworks evolve, the most important operational question is which version governs the service today and which version governs it at renewal. Teams that cannot answer that question will struggle to prove their age-check decisions were made against the right standard.

For practitioners

• Map the legal duty before the supplier Document whether your age-check requirement comes from the Online Safety Act, a sector rule, or an internal policy before evaluating providers.
• Check the register fields, not the sales summary Review the framework version, supplementary codes, certifying body, and certificate expiry for every shortlisted provider.
• Separate provider assurance from service compliance Write procurement language that treats certification as evidence about the provider, not proof that the downstream service is automatically compliant.
• Test the fallback path in the same session Confirm what happens when the first age-check method does not resolve, and verify that the alternative path is still governed and auditable.

Key takeaways

• The Data (Use and Access) Act 2025 governs digital verification service reliability, not the existence of age-check duties.
• A public register improves due diligence, but it does not turn certification into automatic compliance for the buyer.
• Practitioners should separate the legal obligation to check age from the provider evidence used to support that control.

Related NHI Mgmt Group resources: UK Digital Verification Services Trust Framework Guide · UK GDPR and Data Protection Act 2018 Guide · PECR Guide

Key terms

• Digital Verification Service: A Digital Verification Service is a certified service used to verify identity attributes in a standardised way. In regulated settings, the value is not the label itself but the ability to produce evidence that can be relied on, retained, and audited across onboarding and lifecycle decisions.
• DVS Trust Framework: The DVS trust framework is the statutory ruleset that governs how digital verification services are provided in the UK. It defines the reliability baseline for providers, including versioning and certification scope, but it does not itself impose age-check obligations on the organisations that consume those services.
• Trust Mark: A trust mark is a visible signal that an organisation has met the requirements to provide digital verification services within an approved framework. It helps users and relying parties recognise trusted providers more easily. Its value depends on credible registration criteria and ongoing oversight rather than branding alone.
• Public Register: A public register is an authoritative list of registered providers and their certification details. For age assurance programmes, it is useful because it makes provider claims inspectable, including scope, version, certifying body, and expiry, but it does not replace the organisation’s own legal analysis.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.