Security

Encryption in Transit

• TLS 1.2 and 1.3: All traffic between your device and our servers is encrypted in transit
• Perfect Forward Secrecy: Session keys are never reused, protecting past communications
• Certificate pinning is not implemented. The apps rely on the operating system's certificate store, like a browser does

Encryption at Rest

• AES-256-GCM on specific fields: Two-factor secrets and audit-log metadata are encrypted in the database with AES-256-GCM. This is not blanket encryption of every column
• Video and audio never reach our servers at all. Monitoring streams peer-to-peer between your own devices and is end-to-end encrypted; we have no copy to secure
• The database itself does not use transparent data encryption. It runs on standard PostgreSQL, protected by disk-level and access controls rather than TDE
• Backups: off-site backup encryption is supported but is a deployment option, so we do not claim here that every backup is encrypted
• Keys are held in the server environment, not in a managed key service such as AWS KMS, and are not automatically rotated

End-to-End Encryption

Your baby's live audio and video are end-to-end encrypted between your devices, so only the caregivers you invite can see or hear them. We never have access to your encryption keys, and we cannot view or listen to your monitoring streams.

Cloud Infrastructure

• EU-Based Servers: Our relay and TURN servers are hosted in EU data centers (GDPR compliant)
• Reputable Providers: We build on established cloud and infrastructure providers with strong, independently audited security practices
• Minimal Data: Live audio and video pass through our servers only when a direct connection is unavailable, and remain end-to-end encrypted

Network Security

• Firewall Rules: a host firewall refuses incoming connections except to the ports the service needs
• One server, not a private cloud network: production is a single virtual server, so there is no VPC to isolate it in
• Suspicious activity: sign-in attempts are checked automatically (see Monitoring & Logging below); nobody watches the network around the clock
• Rate Limiting: API rate limiting prevents abuse

Server Hardening

• Security updates applied as a priority
• Minimal attack surface with only essential services running
• No scheduled vulnerability scanning or penetration testing yet
• Services defined in version-controlled Docker Compose files and deployed as prebuilt images; the server itself is one long-lived machine, not rebuilt from code

Authentication

• Multi-Factor Authentication (MFA): Optional MFA using TOTP or hardware keys
• Password Requirements: Minimum 8 characters. There is no complexity rule and no breached-password check — both are on our list, and until they exist we are not going to imply they do
• Bcrypt Hashing: Passwords hashed with bcrypt (cost factor 12)
• Session Management: Secure JWT tokens with short expiry times
• Device Tracking: Monitor active sessions and revoke suspicious devices

Authorization

• Role-Based Access Control (RBAC): Granular permissions for team members
• Least Privilege: Users granted minimum necessary permissions
• Workspace Isolation: Complete data isolation between organizations
• Audit Logs: administrators' changes to accounts, roles and permissions are recorded in the audit log

Internal Access

• Jaen is built and run by one person. There is no staff, so there are no employee background checks, no VPN concentrator and no just-in-time access programme to describe — this page used to claim all three
• Production is reached over SSH from the maintainer's own machine; deploys build locally and ship an image, so nothing is compiled on the server
• Administrators' changes to accounts, the website's content, backups and who may download the apps are recorded in the audit log described below — not every admin screen is
• What that means for you: the number of people who can reach your data is one. It also means there is nobody to review that person's changes, which is stated rather than dressed up in the next section

Secure Development

• Automated gate on every change: type-checking, linting and the full backend and frontend test suites run in CI on every push and pull request, and a change that fails any of them does not ship
• A large regression suite: thousands of tests, including ones written specifically to stop a fixed security or privacy defect from coming back
• Code review is not two-person. One person writes this software, so there is no second reviewer and no security-training programme — claiming either would be inventing an organisation
• There is no automated dependency or static security scanning yet. Dependencies are updated by hand; adding an automated audit to CI is open work, and we are not going to describe it as finished

Security Features

• Input Validation: All user input sanitized and validated
• SQL Injection Protection: Parameterized queries prevent SQL injection
• XSS Protection: Content Security Policy (CSP) and output encoding
• CSRF tokens are not currently issued. Requests are authorised by a bearer token; cookie-based sessions also exist, and closing that gap is open work we are not going to describe as finished
• API Security: OAuth 2.0 / JWT for API authentication

Backup Strategy

• Nightly database dumps: a full logical dump of the database is taken on a schedule and verified to be non-empty before it is kept
• The five most recent are retained — not thirty days of snapshots. Manual backups taken before a deploy are kept as well
• Off-site copies are a deployment option, not a guarantee. The script can sync each backup, encrypted, to a single EU object-storage remote — it is switched on by configuration and skips silently when it is not configured, so we will not tell you every backup is off-site
• There is no replica and no second region. Everything runs on one EU server with one database volume, and backups are not automatically restore-tested

Disaster Recovery

• Recovery is a restore, not a failover. Losing the server means rebuilding it and restoring the most recent dump, by hand — there is no standby host to switch to
• So the honest recovery point is the last nightly dump, not five minutes. We do not publish a recovery-time target we have never measured under a real failure
• What your baby monitor does not depend on: live audio and video are peer-to-peer and never stored on our servers, so a server outage cannot lose a stream, and monitoring on your own Wi-Fi keeps working while the site is down
• Incident response is one person, not a 24/7 on-call rota. An external check watches the site from outside our infrastructure and emails the maintainer when it stops answering; nothing pages anybody at 03:00

Security Monitoring

• Login-path threat detection: repeated failures, credential-stuffing patterns and automated clients are scored on every sign-in attempt, and a high-severity result is recorded for review
• You are told about your own account: a sign-in from an IP address your account has never used before — other than the sign-in that creates the account — sends you an email, unless you switch those emails off with Login Notifications on your account's Security page, or ask us to; a sign-in our checks judge suspicious — a country and a device your account has not used before, together — gets a security alert instead, whatever that switch says. Those are the alerts that matter most, and the ones that do not depend on anybody being awake
• This is rule-based, not machine learning. The scoring is thresholds and counters — useful, and much easier to reason about than a model, but we are not going to call it AI
• There is no SIEM and no automated blocking. Detected threats are logged and shown on an internal dashboard; acting on them is a person reading it, and an external uptime check emails the maintainer if the site stops answering

Audit Logging

• What is logged: sign-ins and account security (password changes and resets, two-factor and passkey changes), changes to your own account, including deleting it, and administrators' changes to accounts, the website's content, backups and who may download the apps
• An entry is never edited, except because an account was deleted — when it is deleted, or, for an account deleted before we began doing so, by a one-off repair — and to mark a request for an emailed confirmation link (to delete an account, or for another change we ask you to confirm) as failed when its email could not be sent. Deleting an account deletes the entries of its own actions, except an administrator's entries about other accounts, which are kept; in those, and in the entries about the account that remain — an administrator's action on the account, a sign-in attempt that used its address, any other entry that quotes its address — the address is replaced by a one-way hash and the date of the first account deletion they outlive is recorded, so that they can be deleted 7 years after it
• Log Retention: an entry is deleted 12 months after it was written, or sooner if the account it belongs to is deleted first. One that outlives an account deletion — one that names the deleted account, or an administrator's entry about another account, which outlives the administrator's account — is deleted 7 years after the first account deletion it outlives; for an account deleted before this rule began, its entries that name it by its id go 7 years after the day we applied the rule to them. The record that an account deletion was carried out is kept for 7 years and then deleted, and the record of a request to delete an account is not deleted while the request is still pending. The IP addresses an account has signed in from are deleted 12 months after each was last used, the records of its sign-in sessions 12 months after each ended, and password-reset links 12 months after they expired or were used
• Log Analysis: an administrator can search the audit log in the admin area; nobody reviews it on a schedule

Patch Management

• Security fixes come first: they are applied as a priority, ahead of other work
• No patch deadline is promised. One person maintains Jaen, so there is nobody on shift to meet one

Transparency

• Security incidents disclosed on our status page
• Plain-language security updates so parents always know where they stand
• Public changelog includes security-related updates