As organizations strengthen security around sensitive data, systems, and workflows, identity has become increasingly foundational infrastructure. It sits at the center of access control across use cases and enterprises—and with that comes greater scrutiny around how identity data is collected, used, and protected. 

‍

One thing is clear: Privacy and product security cannot be layered on after the fact. They must be built into the way the product is designed, how data is used, and how changes are managed from the start.

‍

Recently, our Chief Security Officer, Jon Schlegel, shared the standards we believe every organization should demand from an identity provider. Those principles were developed in partnership with our Chief Privacy Officer & General Counsel, Lynn Haaland—reflecting how privacy, security, and legal governance work together at CLEAR. 

‍

These standards are not new for us. They reflect how CLEAR has operated for more than 16 years in the most highly regulated environment, and how that experience shapes the identity platform that powers CLEAR1 today. They center on three core pillars:

• Data is used for its intended purpose
• Security is built into the architecture
• Disciplined operations exist at every stage

‍

Established Boundaries Around How Data is Used

‍

Data is Not Shared Beyond Verification

‍

Within CLEAR1, data is used to complete identity verification for the organization an individual is interacting with—whether that’s an employer, healthcare provider, financial institution, or another enterprise—unless the individual chooses to reuse their verified identity in another CLEAR experience.

‍

We do not share personal data beyond that stated verification context, including with federal agencies. If a federal agency is a CLEAR1 customer (e.g. CMS), we verify directly into that agency’s system, under contract and with explicit user consent, just as we would for any other private organization. That data is not shared outside of that specific use case.

‍

Users Provide Explicit Consent and Retain Control

‍

Verification shouldn’t feel like a black box to the end user. Flows should always communicate: 

• Which organization the individual is verifying with
• Which identity provider is facilitating the verification process
• What data is being collected
• How it will be used

‍

People who verify with CLEAR always know what information is being shared. Explicit consent is required during verification, and individuals can request deletion of their account and associated personal data through a simple process. Transparency is built into the experience itself. 

‍

Biometric Data is Rigorously Protected

‍

Biometric data is among the most sensitive forms of personal information. It requires clear ownership and strict controls around use, storage, and retention.

‍

In this case, CLEAR acts as the controller of biometric data and securely stores it within our own environment. Biometric data never touches customer systems, meaning organizations do not assume biometric storage risk or the associated compliance burden. CLEAR remains responsible for protecting and governing that data.

‍

Security Embedded in Architecture

‍

Encryption is Table Stakes
‍

At CLEAR, data at rest is encrypted using FIPS 140-2 compliant methods. Data in transit is protected using TLS 1.2 with secure cipher suites. Layered defenses include firewalls, intrusion detection, and intrusion prevention systems. These are foundational controls. 

‍

Security is Integrated Across the Product Lifecycle
‍

Encryption is essential, but it’s only part of the picture. 

‍

Most security failures do not stem from broken encryption. They happen because of design flaws, misconfigurations, unreviewed integrations, or weak change control. As such, security teams should be involved in product requirements, architecture review, implementation guidance, and threat modeling from the start—not consulted after development is complete.

‍

At CLEAR, our Product Security team participates in early stages of requirements gathering, design, and production planning for feature releases. We also operate with the understanding that code running in a user’s browser or device can be exposed or manipulated. For that reason, we do not rely on client-side behavior to enforce security controls. Critical security decisions are enforced server-side, within CLEAR’s controlled environment, where they can be governed and audited.

‍

External Integrations Undergo Structured Review
‍

Third-party integrations introduce risk. An identity platform’s security posture is influenced by the vendors and services it depends on.

‍

At CLEAR, vendors undergo a Third-Party Risk Management (TPRM) review during onboarding. Based on risk profile, vendors are subject to periodic recertification. Any new or modified external connection triggers a formal architecture security review led by Product Security before implementation. 

‍

Continuous Operational Discipline
‍

Security does not end at deployment. Production releases move through staged promotion environments before going live. Unit testing and integration testing are required, and major releases undergo end-to-end testing.

‍

Before code can be merged, it must pass:

• Static application security testing
• CodeQL analysis
• Dependency scanning
• Secrets scanning

‍

Every change is tied to a tracked ticket for traceability. All merge requests require manual review. Cross-functional changes are subject to formal change management with multiple reviewers. Feature flags allow controlled rollout and rapid disablement when needed. 

‍

After deployment, monitoring continues. CLEAR runs ongoing dynamic application security testing, continuous attack surface monitoring, and automated detection of misconfigurations. If an issue were to bypass build-time controls, our monitoring systems are designed to identify it quickly.

‍

These practices are reinforced with annual penetration tests on high-risk applications, a bug bounty program, and periodic scanning of infrastructure images used in production.

‍

What This Means for Enterprise Leaders

‍

Evaluating an identity provider requires looking beyond features or user experience. Security leaders should expect clear answers to questions such as:

• How is data use limited to its stated purpose?
• Who controls and stores biometric data?
• Where are security controls enforced—client-side or server-side?
• What structured review governs third-party integrations?
• What testing gates exist before production releases?
• How are changes tracked, reviewed, and monitored after deployment?

‍

Privacy and product security shouldn’t just be differentiators—they are minimum standards for identity infrastructure, and CLEAR1 is built to meet them by default.