Security Policy

Last updated: 18 June 2026

How Tempo protects your data — and how to tell us if you find something we should fix.

How we protect your account

Passwords are hashed with Argon2id. We never store or see your plain-text password. Not in the database, not in logs, not in tickets.
Sessions are server-side. The cookie we set is an opaque identifier; the actual session state lives on our servers and is invalidated immediately when you log out or change password.
CSRF protection on every state-changing request. Tokens are bound to your session and rotated on login.
Rate limiting on signup, login, password reset, and reporting, with stricter limits for failed attempts.
Audit logging. Every login, profile change, moderation action, and admin action is recorded in an append-only log. We can tell you what happened to your account and when.

How we protect your data

TLS everywhere. All connections to Tempo use TLS 1.2 or higher. We do not accept unencrypted HTTP for any authenticated endpoint.
Database encryption at rest. Our Postgres cluster runs on encrypted volumes. Backups are encrypted with a separate key.
Photo storage is private by default. Object storage ACLs are private; access is brokered by short-lived signed URLs scoped to the viewer authorised to see the photo.
Identity-verification documents are not stored on Tempo. Our verification provider holds them under their own retention; we keep only a pass/fail signal and the minimum metadata.
NCII image submissions are hashed in memory and discarded. Image bytes never touch disk. See /safety/submit-hash and Privacy Policy §2.5.
No third-party analytics or tracking pixels. We don't load Google Analytics, Facebook Pixel, ad networks, or anything else that exfiltrates your browsing to a third party.

Vulnerability disclosure

If you've found a security issue in Tempo, we want to hear about it. Email [email protected] with a description of the vulnerability, how to reproduce it, and any thoughts you have on impact. Our machine-readable /.well-known/security.txt repeats these details in RFC 9116 format.

What you can expect from us:

An acknowledgement within 3 business days.
An assessment of severity and a plan within 14 days.
Credit for the discovery if you want it (and not if you don't).
A status update at least every 30 days while the issue is open.
Notification when the fix is deployed.

What we ask from you:

Don't access, modify, or delete data belonging to anyone but yourself. If a vulnerability happens to expose another user's data, stop, don't download it, and tell us.
Don't perform denial-of-service testing, send spam, or do anything destructive.
Don't social-engineer staff or contractors.
Give us a reasonable window to fix before public disclosure. 90 days is the industry default; we can usually move faster.

We operate a safe harbour for good-faith security research conducted under this policy: we will not pursue civil or criminal action against you, and we will ask any third party not to either, provided you stay within the rules above.

Tempo is a small team. We do not currently run a paid bug-bounty programme. If that changes we will announce it here.

If something goes wrong

If we discover a personal-data breach that materially affects you, we will notify the Dutch Autoriteit Persoonsgegevens within 72 hours (as required by GDPR Art. 33) and notify you directly without undue delay (Art. 34). We will tell you what happened, what data was involved, what we are doing about it, and what you should do.

Live service status: status.optimcloud.com/status/tempo.

Things we are still working on

Honest about the roadmap rather than claiming things we don't yet have:

Two-factor authentication via TOTP. Coming soon, ahead of any feature that lets users send money.
Cross-platform NCII hash sharing (StopNCII/PhotoDNA integration). The self-hosted block list is live today (ADR-0012 v1); the wider industry integration is in our roadmap.
End-to-end encryption of private messages. Currently messages are encrypted in transit and at rest but are decryptable by us when we have to moderate a reported conversation. True E2E is a long-term goal.
External security audit and penetration test. Planned before any major user-acquisition push.

Security questions: [email protected].