Cryptography Policy
| Field | Value |
|---|---|
| Document ID | CRP-001 |
| Version | 1.1 |
| Classification | Internal |
| Owner | Lauren ten Hoor (Director) |
| Effective date | 2026-05-25 |
| Next review | 2027-04-30 |
| Parent policy | Information Security Policy (ISP-001) |
1. Purpose
To define the cryptographic standards and key-management practices used by the Company to protect the confidentiality and integrity of information, and to ensure that those standards remain current with industry guidance.
2. Scope
All cryptographic protections applied to Cadences.work systems and information, whether implemented by the Company directly or relied upon from sub-processors.
3. Roles
| Role | Responsibility |
|---|---|
| Director | Approves the cryptographic standards in §4 and any deviations |
| Information Security Officer (Director) | Operates key rotation, monitors deprecation of algorithms |
| Sub-processors | Implement and maintain platform-level cryptographic protections |
4. Cryptographic standards
4.1 Encryption in transit
| Use | Standard |
|---|---|
| Public-facing web traffic | TLS 1.2 minimum; TLS 1.3 preferred. HSTS enforced with max-age ≥ 1 year, includeSubDomains, preload. |
| Application → Supabase | TLS 1.2+ enforced by Supabase |
| Application → OpenAI / Postmark | TLS 1.2+ enforced by provider |
| Email transport | Opportunistic TLS via Postmark; STARTTLS where receiving servers support it |
| Internal CI / GitLab | TLS 1.2+ |
Insecure protocols (HTTP, FTP, Telnet, SMB1, SSL 3.0, TLS 1.0, TLS 1.1) shall not be used for production traffic.
4.2 Encryption at rest
| Asset | Standard |
|---|---|
| Production database | AES-256, provider-managed (Supabase) |
| Object storage | AES-256, provider-managed (Supabase Storage) |
| Backups (Supabase PITR) | AES-256, provider-managed |
| Founder's workstation | Full-disk encryption (FileVault) |
| Founder's mobile device | Full-disk encryption (iOS / Android default) |
| Local source-code mirrors on external drives | AES-256 (FileVault-encrypted external volume) |
4.3 Hashing
| Use | Standard |
|---|---|
| User passwords (only where retained by Supabase Auth — end-user sign-in is passwordless by default) | bcrypt with provider-default cost |
| Magic-link / OTP tokens | one-time, hashed-at-rest by Supabase Auth before storage |
| File integrity | SHA-256 minimum |
MD5 and SHA-1 shall not be used for security purposes.
4.4 Asymmetric cryptography
| Use | Standard |
|---|---|
| TLS certificates | RSA 2048+ or ECDSA P-256+; managed by Vercel via Let's Encrypt |
| Application session JWTs (Supabase Auth access tokens) | ECDSA P-256 (ES256). Tokens are signed by Supabase Auth and verified by the application against the public JWKS retrieved from ${SUPABASE_URL}/auth/v1/.well-known/jwks.json. The application does not hold or have access to the private signing key. |
| Code signing (when introduced) | RSA 3072+ or ECDSA P-256+ |
| SSH keys | Ed25519 preferred; RSA 4096 acceptable |
| PGP for sensitive disclosures | RSA 4096 or Ed25519 |
4.5 Random number generation
Cryptographic random values shall be obtained from cryptographically secure random sources only (crypto.getRandomValues, crypto.randomBytes, /dev/urandom). Math.random() shall not be used for security purposes.
5. Key management
5.1 Storage of secrets
- API keys, signing keys, and database credentials are stored in:
- Vercel environment variables for production runtime;
- Supabase Vault (where applicable);
- the Company password manager for human access;
- never in source code, plain-text files, browser autofill, or the founder's notes app.
5.2 Rotation
| Type | Rotation cadence |
|---|---|
| User passwords | Not enforced on schedule (NIST 800-63B aligned), but rotated immediately on any suspicion of compromise |
| API keys (sub-processors) | Annually, and immediately on any suspicion of compromise |
| Supabase Auth JWT signing key (ES256) | Annually; and immediately on any suspicion of compromise. Rotated in the Supabase dashboard (Project Settings → JWT Keys). Existing sessions remain valid until token expiry (~1 hour); the JWKS endpoint publishes the new public key on rotation so application-side verification picks it up automatically. |
| TLS certificates | Automatic (Vercel / Let's Encrypt) |
| Hardware authentication tokens (if introduced) | When lost, transferred, or after a known compromise; the Company maintains at least one backup token. No dedicated hardware tokens are in use today — see ACP-001 §4.2. |
5.3 Customer-managed keys
The Company does not currently offer Customer-Managed Keys (CMK / BYOK). If a customer requests CMK as a contractual condition, the request is evaluated as a feature request and implementation is scoped against the Change Management Policy.
5.4 Compromise response
On confirmed or suspected compromise of any cryptographic key:
- The key is rotated immediately;
- Systems that consumed the key are redeployed with the new key;
- Logs are reviewed for anomalous activity during the window of exposure;
- An incident record is opened per the Incident Management Policy.
6. Algorithm review
Cryptographic algorithms and key sizes are reviewed at least annually against current guidance from:
- ENISA — Algorithms, key size and parameters report;
- NIST SP 800-131A — Transitioning the use of cryptographic algorithms and key lengths;
- BSI TR-02102 — Cryptographic mechanisms: Recommendations and key lengths.
Deprecated algorithms are scheduled for removal with a defined sunset date.
7. Compliance and references
ISO/IEC 27001:2022 Annex A: A.8.24 (use of cryptography), A.5.31 (legal, statutory, regulatory and contractual requirements).
GDPR Article 32(1)(a) (the pseudonymisation and encryption of personal data).
Singapore PDPA — Protection Obligation (Section 24).
8. Version history
| Version | Date | Author | Summary |
|---|---|---|---|
| 1.0 | 2026-04-30 | Lauren ten Hoor | Initial issue |
| 1.1 | 2026-05-25 | Lauren ten Hoor | §4.4 — named application JWT signing (ES256) as a standard, including the JWKS-based verification model. §5.2 — added rotation cadence for the Supabase JWT signing key. Issued alongside the May 2026 migration of Supabase Auth from symmetric (HS256) to asymmetric (ES256) JWT signing keys. |