No customer identity stored on your side

Most platforms store customer usernames and email addresses as the mechanism for identifying users on return visits. Those identifiers sit in your database, exposed to any attacker who breaches it, and create GDPR obligations around storage, retention, and breach notification.

When a customer authenticates through WWPass, your service receives a Protected User Identifier (PUID) — an opaque, randomly generated string specific to that customer's relationship with your service only. You do not need to store a username or password to verify who they are. Whatever user information your service needs to operate — name, email, account details — remains under your control, but the authentication credential is gone from the equation.

The same customer appears differently to every service they access through WWPass. A breach at your platform exposes no authentication credentials. Cross-service correlation through stolen login credentials is impossible by design.

Explore WWPass PUID ∙ Protected user identifier

Self-provisioning at scale

Customer authentication at scale has different requirements from workforce authentication. Customers are not IT-managed. They cannot be issued hardware tokens by an IT department. They provision themselves, on their own devices, without administrative support.

WWPass supports both administered provisioning — where an organization issues and manages keys for known users — and self-provisioning — where customers issue their own keys independently. The Public Wireless Internet Service Provider deployment in the WWPass customer portfolio uses both models in the same platform: administered provisioning for registered subscribers and self-provisioning for ad-hoc customers.

The WWPass Key app is available free on iOS and Android. Customers download it, provision themselves, and authenticate on any device and browser without IT involvement. No secure enclave required. No specific operating system required. Works at any scale.

Explore WWPass Key

Regulatory compliance for customer-facing platforms

Platforms authenticating customers in regulated industries face specific authentication requirements from multiple frameworks:

GDPR: storing customer email addresses and usernames as authentication credentials creates obligations for data minimization, breach notification, and retention limits. 

WWPass removes the need to use personal data such as email addresses during authentication. Customer information your service holds for its own operational purposes is unaffected — but the authentication process itself cannot be phished for that data, and it cannot be used to link customer activity across services.

PSD2 Strong Customer Authentication: financial platforms must implement SCA using possession, knowledge, or inherence factors. WWPass Key satisfies the possession factor. An optional PIN satisfies the knowledge factor. Biometric satisfies the inherence factor. No shared secret is transmitted to the service at any point.

HIPAA: healthcare platforms authenticating patients must implement access controls that protect personal health information. WWPass stores no username tied to a patient record. The PUID is opaque and non-human-readable, meaning a breach reveals no connection between the identifier and the patient's identity.

Explore WWPass for financial services & fintech

Real deployments

Public Wireless Internet Service Provider: a maximum-flexibility solution authenticating both subscriber customers and ad-hoc customers through the WWPass Key app. Administered provisioning for registered subscribers, self-provisioning for ad-hoc users. Both customer types authenticate without a username or password.

SaaS Document Management Platform: strong customer authentication was required for both internal administrators and external clients under GDPR. WWPass replaced username and password login for both user types. External clients authenticate with a WWPass Key without the platform storing their email address or username. Transition from proof of concept to full deployment took three months with no disruption to normal operations.

What changes for product and platform teams

• No credential database to protect. Your platform stores PUIDs, not usernames or passwords. A breach of your infrastructure yields no usable customer identity data and triggers no GDPR breach notification obligation for credential exposure.

• No customer-facing password reset flows to build. Customers manage their own keys through self-service. The most common customer support request — password reset — does not exist.

• No device dependency. WWPass works on any device and browser. No secure enclave, no specific operating system. Essential for consumer platforms with heterogeneous user device environments.

• No cross-service correlation risk. Each customer receives a different PUID per service. If your platform is breached alongside another platform, no customer identity can be linked across the two datasets.

Explore WWPass Authentication

Frequently asked questions

Q: Does WWPass store customer identity data on behalf of the platform?

A: No. WWPass generates a Protected User Identifier (PUID) for each customer-service relationship. This is an opaque randomly generated string specific to that customer's relationship with that service. Neither the platform nor WWPass stores the customer's email address, username, or any persistent identity marker beyond the PUID. The PUID cannot be reversed to recover the customer's identity.

Q: How do customers provision their own WWPass Key?

A: Customers download the free WWPass Key app on iOS or Android and provision themselves without administrator involvement. For platforms that require managed provisioning — where customer access is controlled by the organization rather than self-service — administered provisioning is also supported. Both models can run on the same platform simultaneously.

Q: Does WWPass satisfy PSD2 Strong Customer Authentication requirements for financial platforms?

A: Yes. WWPass Key satisfies the possession factor under PSD2 SCA. An optional PIN satisfies the knowledge factor and biometric the inherence factor. No shared secret is transmitted to the service at any point. Confirm specific compliance mapping with your legal and compliance team before publishing compliance claims.

Q: What does a customer do if they lose their WWPass Key?

A: The customer uses their Service Key to revoke the lost key and issue a new one without administrator involvement. The WWPass Key App can additionally be restored using a registered backup email. Access is restored without any password reset flow because there is no password.

Q: Can WWPass customer authentication work at millions of users?

A: Yes. WWPass works on any device and browser at any scale. The distributed architecture has no single point of failure and no central credential database that becomes a bottleneck. Self-provisioning means customer onboarding does not require IT resources regardless of scale.