Security Posture · Britemet Inc.

Everything we do to keep your data safe.

The full control list for Britemet Home - product first, platform and policy after. Where something is a design target or beta-only, we say so. Overview: Security.

Encryption Roles Sign-in Audit Files Evidence App & mobile Platform
Britemet Home

Eight control groups.

Mechanisms in the shipping product and production foundation - not a sales brochure of future hope.

About the hedges below. Phrases like “where implemented”, “as deployed” and “as a design goal” are load-bearing, not padding. An unqualified line means the control is in the shipping product today. A qualified one means it is real but its coverage depends on configuration or environment, and we would rather name that than let you assume more than we can show. Anything we have not built at all is simply absent from this page.

8 control groups

Grouped the way a household or a security review actually asks.

01 · Secrets and encryption

Vault data stays sealed until you open it

  • Field-level AES-256-GCM on Wi-Fi passwords, safe / alarm / gate / garage codes, and optional medical vault fields (allergies, medications, conditions, notes).
  • Envelope encryption with a data key per sensitive record, wrapped under managed keys (AWS KMS in production).
  • Additional authenticated data (AAD) binds ciphertext to household, record, and field so keys cannot be casually reused across tenants or fields.
  • Hidden by default - sensitive values are not rendered into ordinary page HTML; reveal is an explicit action.
  • TLS in transit; databases and object storage use encryption at rest with managed keys.
  • Exports keep vault fields encrypted (ciphertext in export where designed that way) so a download is not a cleartext dump of codes.
02 · Who can see what

Five roles, one household boundary

  • Roles: Owner, Admin, Member, Child, Sitter - not one shared password for the house.
  • Tenant isolation: domain data is household-scoped; access comes from membership, not from guessing an ID.
  • Children get day-to-day context (contacts, vendors, maintenance, chores, emergency card) without finances, full documents, or vault codes.
  • Sitters get a limited, expiring, read-only view (guides, pets, emergency context, guest Wi-Fi where configured) - not the vault, not documents, not finances.
  • Member management is restricted to Owner / Admin.
  • Brit (optional AI) only uses records your role can already see; vault secrets are designed never to go to a model.
03 · Sign-in and sessions

Credentials and session hygiene

  • Password hashing with modern one-way hashing (bcrypt, cost 12); login errors do not reveal whether an email is registered.
  • Minimum password length of 12 characters; password change and reset revoke other sessions.
  • Server-side sessions - random tokens in httpOnly cookies (Secure in production, SameSite=Lax); the database stores a hash of the token, not the live secret.
  • Every authenticated surface re-checks the session - the product does not trust client-only state for household access.
  • Two-factor sign-in where enabled: authenticator enrolment and device session management from account settings.
  • Password-reset links are emailed in production rather than returned in an API response.
04 · Accountability and privileged paths

Sensitive actions leave a trail

  • Audited vault reveals - who opened a secret, and when (fail-closed on sensitive paths that require audit).
  • Broader audit coverage for sign-ins, document uploads, membership changes, sitter-link lifecycle, and data exports.
  • Control-plane evidence is not writable by the normal application role.
  • Support stays in-app for ticket bodies rather than pasting household content into ordinary email.
  • Rate limits on login, secret reveal, and assistant traffic (edge / app level as deployed).
05 · Files and documents

Uploads are not a free-for-all

  • Malware / DLP scanning on uploads; blocked or infected verdicts cannot be silently marked clean.
  • Private object storage in production (S3) with server-side encryption (SSE-KMS) and no public bucket access as the design.
  • Randomized storage names; downloads go through an authenticated path that re-checks grant and scan state.
  • Attributed access on document download where implemented.
  • Size caps on uploads (product limit applied server-side).
06 · Evidence integrity (claims and disasters)

Proof that does not rest only on our word

  • Disaster snapshots are hashed (SHA-256) so content can be verified later.
  • Independent RFC 3161 timestamps from a third-party time-stamping authority when that path is configured - so the seal date is not only our wall clock.
  • WORM-oriented storage for sealed snapshot / audit objects where Object Lock retain-until is applied (immutable for the retention window).
  • Honest status if a seal layer is unavailable - local hash still succeeds; the product does not invent a third-party stamp.
07 · Application and mobile hardening

Web app, APIs, and the phone vault

  • Security headers on the product edge (CSP, frame denial, nosniff, HSTS, permissions policy as configured).
  • CSRF resistance via SameSite cookies and server-action / authenticated write patterns - not open cross-site writes.
  • Parameterized database access (Prisma) and server-side input coercion on writes.
  • Write guards on mutations: role and billing entitlement checked server-side, not only in the UI.
  • Mobile vault (beta app): Face ID or fingerprint before every reveal; screenshots blocked while open; values held in memory only, auto-hidden after 30 seconds, not written cleartext to device storage.
  • Capability links (sitter, calendar feeds) are token-gated, rate-limited, and revocable - rotate them when shared.
  • Deterministic safety triage in the Repair Room for gas / CO / electrical burning smells - fixed rules with cited sources, not a free-form model decision.
08 · Platform, ops, and policy

How Britemet Inc. runs the service

  • AWS production foundation: private compute targets, RDS with encrypted storage, KMS for application vault keys, Secrets Manager for runtime secrets, S3 for documents and audit artifacts, TLS at the edge.
  • Network segmentation as a design goal: public edge, private application tier, isolated data tier (VPC layout in infra).
  • Observability: CloudWatch, CloudTrail, and security monitoring services in the production stack map - detection and ops, not a substitute for product RBAC.
  • Secrets stay out of images - injected at runtime, not baked into containers.
  • AI boundary: optional Brit on AWS Bedrock under our account; vault / medical vault designed never to reach a model; household AI can be turned off in Settings.
  • No sale of personal data to advertisers; no secondary market in household records; subscription funds the product. Detail: Why Britemet and Privacy Policy.
  • Export and leave: full household export from the product; account close and deletion paths with documented retention goals in privacy materials.
  • Certification honesty: controls are architected to support future SOC 2 / ISO 27001-style reviews. Britemet Home is not currently SOC 2 or ISO 27001 certified. We will not claim otherwise.

Questions about this list: security@britemet.com · contact form · Security overview · Privacy Policy · AI Policy.

Back to the overview

Pillars, data policy, and how to report a vulnerability live on the Security page.

Security overview Start Home free