Unique First-time Passwords with One-Time Use

Effective: March 17, 2026 · DCF-352

1. Purpose

This policy establishes requirements for unique first-time passwords, one-time use authentication tokens, and secure initial access provisioning at H33.ai. As a company that builds and operates post-quantum authentication infrastructure, H33.ai applies the highest standards to its own credential management, ensuring that first-time access credentials are unique, time-limited, and cryptographically secured.

2. Scope

This policy applies to all systems, services, and applications used by H33.ai personnel, including:

• H33.ai internal systems and administrative consoles
• Auth1 authentication service (H33 subsidiary, included in SOC 2 and HIPAA audits)
• AWS infrastructure accounts (IAM users and roles)
• GitLab source control access
• Microsoft 365 accounts
• Customer-facing API key provisioning

3. Identity Provider

H33.ai serves as its own identity provider, using its proprietary post-quantum authentication stack:

4. First-Time Access Provisioning

4.1 Unique Invitation Tokens

When new personnel are granted access to H33.ai systems, the following controls apply:

• Uniqueness: Each invitation token is cryptographically unique, generated using a CSPRNG (cryptographically secure pseudo-random number generator) with a minimum of 256 bits of entropy
• Single-use: Invitation tokens are invalidated immediately upon first use. A used token cannot be reused under any circumstances.
• Time-limited: Invitation tokens expire after 24 hours from issuance. Expired tokens are automatically purged from the system.
• Delivery: Invitation tokens are delivered out-of-band (separate from the system they grant access to) via a secure channel. The token and the access URL are never sent in the same communication.
• PQ-signed: All invitation tokens are signed with CRYSTALS-Dilithium (ML-DSA) to prevent tampering and ensure authenticity.

4.2 Initial Password Setup

Upon first access using the invitation token, users are required to:

1. Establish a unique password meeting complexity requirements (see Section 5)
2. Enroll biometric credentials via FHE-encrypted biometric capture (see Section 6)
3. Configure multi-factor authentication (see Section 7)
4. Acknowledge the Acceptable Use Policy

5. Password Requirements

For systems where password-based authentication is used (in conjunction with biometric MFA):

6. Biometric Enrollment

H33.ai's primary authentication mechanism uses FHE-encrypted biometric verification:

• Capture: Biometric data is captured on the user's device and immediately encrypted using BFV FHE (N=4096) before transmission
• Template storage: Enrolled templates are stored in FHE-encrypted form. Biometric data is never decrypted at rest on H33.ai servers.
• Verification: Authentication is performed via homomorphic inner product computation on encrypted data. The server never sees raw biometric data.
• SIMD batching: 32 users per ciphertext (4096 slots / 128 dimensions) for efficient batch verification
• Template protection: Templates are further attested with Dilithium signatures and verified via STARK proofs

7. Multi-Factor Authentication

MFA is required for all H33.ai accounts without exception:

• Biometric factor: FHE-encrypted biometric verification (something you are)
• Knowledge/possession factor: Password or hardware token (something you know / something you have)
• Session tokens: Signed with Dilithium (ML-DSA) and transmitted via Kyber-protected channels
• OTP delivery: SMS OTP via Twilio (primary) with AWS SNS failover for Auth1 authentication flows

8. Password Rotation

9. Prohibited Practices

The following practices are strictly prohibited at H33.ai:

• Shared accounts: Every user must have a unique, individually assigned account. Group or shared credentials are not permitted.
• Default passwords: No system, service, or device may operate with vendor-supplied default passwords. All defaults must be changed before production deployment.
• Hard-coded credentials: No credentials, API keys, tokens, or secrets may be embedded in source code, configuration files committed to version control, or application binaries. All secrets are stored in AWS Secrets Manager or environment variables.
• Password sharing: Passwords, tokens, and biometric data must never be shared between individuals
• Credential caching: Browsers and applications must not be configured to auto-fill or cache passwords for H33.ai systems

10. Customer API Key Provisioning

For H33.ai customers receiving API access:

• API keys are generated with 256 bits of cryptographic randomness
• Keys are displayed exactly once at creation time and cannot be recovered (only regenerated)
• Each key is scoped to a specific tenant namespace
• Key provisioning requires authenticated access via Auth1
• Keys are signed with Dilithium for tamper detection

11. Monitoring and Enforcement

• Failed authentication attempts are logged and monitored via DataDog
• Anomalous login patterns trigger automated alerts to the CISO
• Account lockouts are reviewed within 4 hours during business hours
• Password policy compliance is enforced programmatically; non-compliant passwords are rejected at creation

12. Review Schedule

This policy is reviewed annually, or sooner if:

• A credential-related security incident occurs
• NIST or industry guidance on authentication best practices is updated
• Changes to H33.ai's authentication stack require policy updates

The next scheduled review is March 2027.