What Is a Password Compliance Certificate? The Complete Guide

The audit evidence problem

Every SOC 2 audit, HIPAA assessment, PCI-DSS review, and ISO 27001 certification includes a question that stumps most security teams:

"How do you prove that your passwords were generated according to policy — not just that a policy exists?"

The honest answer, for most organisations, is: they can't. They have a written password policy. They may have Active Directory screenshots showing policy enforcement. But they have no cryptographic, tamper-evident, machine-readable record that any specific credential was generated to a specific compliance standard.

The workarounds are inadequate:

• Screenshots — not tamper-evident, point-in-time, manually alterable
• Self-attestation — requires the auditor to trust the auditee
• Policy documents — prove intent, not execution
• Access logs — prove access patterns, not credential quality

A password compliance certificate solves this. It is a signed, machine-readable, independently verifiable record that a specific credential was generated to a specific compliance standard at a specific point in time.

What a compliance certificate is

A password compliance certificate is a cryptographically signed document — specifically a JSON Web Token (JWT) signed using the ES256 algorithm (ECDSA with P-256 curve) — that records the compliance-relevant properties of a credential at the moment of generation.

It proves three things:

1. The credential was machine-generated — not human-chosen, not manually typed, not taken from a previous generation
2. The generation used a validated entropy source — specifically crypto.getRandomValues(), which is FIPS 140-3 aligned
3. The generation parameters met the stated compliance standard — minimum length, character classes, entropy threshold, and other standard-specific requirements were all satisfied

Critically: the certificate never contains the password itself. PassGeni's zero-knowledge architecture means the password is generated client-side in the user's browser and is never transmitted to any server. The certificate captures compliance properties without the sensitive secret.

What the certificate contains

Every PassGeni compliance certificate is a JWT with a signed payload containing:

The entire payload is signed with PassGeni's ES256 private key. The corresponding public key is published at passgeni.ai/.well-known/jwks.json per RFC 7517, enabling offline verification by any auditor.

How PassGeni certificates work

The certificate generation flow is designed to eliminate trust gaps:

1. Password generated client-side — your browser calls crypto.getRandomValues(). The password never leaves your browser.
2. Parameters sent to server — only generation parameters (length, character classes, compliance standard, entropy target) are sent. Not the password.
3. Server validates parameters — PassGeni re-validates that the stated parameters actually meet the compliance standard. The server never trusts the client's compliance claims.
4. Server issues generation session token — a short-lived signed token (generation_session_id, expires in 60 seconds) proves the parameters were server-validated.
5. Certificate issued against session token — the certificate endpoint only accepts a valid generation_session_id. This architectural constraint prevents certifying externally-created passwords.
6. JWT signed and stored — PassGeni signs the certificate with its ES256 private key and stores the JWT in the certificates database. The password is never stored.
7. Certificate URL returned — you receive a public URL at passgeni.ai/cert/[id]. Share this with auditors.

Zero-knowledge vs certified mode

PassGeni operates in two distinct modes, serving different use cases:

• Zero-knowledge mode (default) — Password generated entirely in your browser using crypto.getRandomValues(). No data leaves your browser. No server call. No record created. Zero possibility of server-side breach of your credentials. Use this for generating passwords you will store in a password manager without needing compliance evidence.
• Certified mode — User requests a compliance certificate. The client sends only generation parameters (never the password) to the server. Server validates parameters, signs certificate, stores JWT. Compliance certificate URL is returned. Use this when you need audit evidence that a specific credential meets a specific standard.

In both modes, passwords are never transmitted to or stored by PassGeni. The architectural difference is that certified mode creates a server-side record of generation parameters — not the credential itself. This distinction is mathematically enforced, not policy-based.

How auditors verify certificates

Certificate verification requires no login, no PassGeni account, and no trust in PassGeni's infrastructure. Any party with basic security tooling can verify in under 60 seconds:

1. Navigate to the certificate URL — passgeni.ai/cert/[id]. The certificate page shows compliance claims in human-readable form.
2. Verify the ES256 signature offline — fetch the JWT from the certificate page, use any JOSE library (jose, python-jose, golang-jwt), and verify against the public key at passgeni.ai/.well-known/jwks.json.
3. Confirm the claims — check iss is passgeni.ai, exp is in the future, compliance_standard matches the required framework, and standards_met includes all required standards.
4. Check revocation status — the certificate page at passgeni.ai/cert/[id] shows current validity including revocation. For audit-critical verification, online check is recommended over JWT-only verification.

Verification confirms: the certificate is authentic (PassGeni signed it), the content is unaltered (signature is valid), and the claims are current (not expired, not revoked). This takes approximately 60 seconds and requires no special access to PassGeni systems.

Who needs compliance certificates

Compliance certificates are most valuable for:

• Security engineers preparing audit evidence — SOC 2, HIPAA, PCI-DSS, ISO 27001 auditors ask for password control evidence. Certificates provide machine-readable proof that replaces manual documentation.
• DevOps and SRE teams managing service accounts — service account credentials are the highest-risk credentials in any infrastructure. A certificate provides provenance documentation that can be stored alongside the credential in a secrets manager.
• Enterprise CISOs building compliance programs — a certificate dashboard showing compliance coverage across all organisational credentials replaces spreadsheet-based tracking.
• Healthcare IT teams under HIPAA — HIPAA §164.312 requires evidence of appropriate access controls. Compliance certificates document that credentials were generated to HIPAA-standard parameters.
• Government contractors under FIPS 140-3 / CMMC — documented entropy source and provenance are explicit requirements. PassGeni certificates satisfy both.
• SaaS companies pursuing SOC 2 Type II — Type II audits require evidence that controls operated consistently over time. A library of compliance certificates for all sensitive credentials demonstrates consistent enforcement.

Standards covered

PassGeni currently issues compliance certificates for six frameworks:

Each certificate includes a standards_met array listing every standard the credential satisfies — not just the primary standard requested. A FIPS 140-3 certificate for a 20-character credential with full character set will typically carry all six standards in the array, meaning one certificate can serve as evidence for multiple concurrent audit requirements.

Revocation and expiry

Compliance certificates have a defined lifecycle:

• Default expiry: 1 year — the exp claim in the JWT is set to 365 days from issuance. This aligns with typical credential rotation cycles. An expired certificate shows expired status on the certificate page.
• Revocation — certificates can be revoked manually (e.g. when a credential is rotated or a team member departs). Revoked certificates show revoked status at their URL. The ES256 signature remains mathematically valid after revocation — the public key verification confirms authenticity only; the certificate URL confirms current validity.
• Renewal — when a credential is rotated, generate a new PassGeni certificate for the new credential. The old certificate provides the historical audit trail; the new certificate covers the current credential.

For audit-critical workflows, always verify via the certificate URL (passgeni.ai/cert/[id]) rather than JWT-only offline verification. The URL provides current revocation status; offline verification confirms authenticity only.