Security, in full
Exactly what BrightPath can and cannot do with a child's information.
No hand-waving and no “bank-grade” slogans. Here is the encryption, the keys, the access rules, and the honest limits, in plain language, so a clinic can decide with the facts in front of it.
This page describes the mobile app, which is the most complete today. BrightPath is built on one cross-platform encryption contract, the same AES-256-GCM envelope and test vectors, so the model carries across the web and the Android app in progress. The device-specific pieces, like where each platform keeps its keys, naturally differ. See how each platform encrypts.
The core idea
A name becomes ciphertext before it leaves the device.
Every protected field is sealed on the device with AES-256-GCM. The key that opens it is generated on the device and never leaves it in a readable form. Here is the same field on the device and in the cloud.
The therapist types a name. It is readable only here, in memory on the device.
What syncs to the server is ciphertext. Anyone with raw database access sees this, not the name.
What is protected
What is encrypted, and what stays readable on purpose.
The protection covers the content that identifies a child. Some fields are deliberately left readable because the database has to filter and sort on them, and hiding them would break the app.
Encrypted on the device
- A child’s first name, last name, sex, and date of birth
- Diagnoses on the child record
- Behaviour (ABC) logs: antecedent, behaviour, consequence, and notes
- Care-team message bodies and their last-message previews
- Session notes: pre-session, per-trial, summary, and sign-off
- Assessment session notes
- Treatment-plan writing: summary, caregiver priorities, strengths, needs, and clinical approach
- The parent-readable copies of a child’s name and date of birth
Readable by design
Role, clinic id, and record status
The app filters and routes on these on every screen.
Timestamps
Schedules and histories have to sort by time.
Assignment and roster ids (which therapist, which caregiver)
These decide who is even allowed to open a record.
Message sender name and role; ABC tags, intensity, and duration
List views and trend charts read these without opening the record.
A non-identifying label and search tokens
So the roster can be searched without decrypting every child.
The keys
Three kinds of key, and who is allowed to hold each.
Keys are 256-bit, generated on the device, and stored only in its secure storage. They are never uploaded in a readable form and never leave the device.
Clinic key
crypto.shared.clinicAll of a clinic’s encrypted records. Issued to a staff device only after the rules confirm the role.
Held by: Clinic staff devices
Caregiver key
crypto.shared.caregiverOnly the parent-readable copies of their own child’s information. A parent never receives the clinic key.
Held by: A verified parent’s device
User key
crypto.user.privateData that belongs to one person’s own context.
Held by: A single user’s device
Getting a key to a new device
How a new device gets the key, without the server ever holding it.
When a therapist sets up a new device, or a parent joins, that device needs a key. It is delivered through a public-key handshake, so the key is only ever readable on the device it is meant for.
- 1
The new device asks, without revealing a secret
It publishes only its public wrapping key (a P-256 ECDH public key). Nothing that could decrypt data leaves the device.
- 2
A key holder re-wraps the key to that device
A device that already has the key, or the server key authority, re-wraps the content key to the new device’s public key using P-256 ECDH, HKDF-SHA256, and AES-256-GCM. Only that one device can unwrap it.
- 3
The device verifies before it trusts
It checks the delivered key against a write-once SHA-256 fingerprint in the registry. Wrong or tampered key bytes are rejected, even from a misbehaving sender.
- 4
The server issues strictly by role
Staff devices can receive clinic keys. A verified caregiver receives the caregiver key and nothing more. The server never holds a plaintext key or any readable information.
What BrightPath does
Nine things the security model actually delivers.
Sensitive fields are encrypted on the device with AES-256-GCM
Each protected field is sealed on the device into a versioned envelope (AES-256-GCM, a fresh random nonce every time, a 128-bit authentication tag) using the device’s built-in cryptography. What the server receives is ciphertext, a nonce, a tag, and a key id.
Each encrypted value is bound to its exact place
The envelope authenticates a context of scope, clinic, document, and field. If a ciphertext is copied into a different record or field, it will not decrypt. The binding is enforced by the encryption itself, not by app code that could be skipped.
Keys are generated on the device and kept in its secure storage
256-bit keys are generated on the device and held in its secure storage, available only after the device is unlocked and never synced off it. If no clinic key is present, the app refuses to save rather than write in the clear.
A new device or a parent gets keys wrapped to itself
Key delivery uses a public-key handshake, so the server relays only key material that a specific device can unwrap. The server never sees a plaintext key or any readable information.
Parents read their own child without the clinic key
A separate caregiver key backs parent-readable copies of a child’s details. Staff write both a staff copy and a caregiver copy; the two are cryptographically distinct, so a parent decrypts their own child and nothing else.
Access is decided by role-aware rules with default-deny
Authentication plus server-side access rules decide who can read or write each record, by role and clinic, ending in an explicit deny-everything-else. Encryption sits behind this as a second wall. The rules are covered by an automated test suite that runs in CI.
Encrypted in transit, and again at rest
All traffic to the server is over TLS. The cloud provider encrypts the whole database at rest, and BrightPath adds field-level AES-256-GCM on top, so the sensitive fields are unreadable even to someone with raw database access who lacks a device key.
Notifications carry nothing that identifies a child
A reminder says something like “Your session starts in about an hour” plus an opaque id the app resolves only after unlock. No name, note, title, or location is ever in a push payload, so a lock screen and the delivery network see nothing sensitive.
The honest limits
What BrightPath does not claim.
A security page that only lists strengths is not telling you the truth. These are the real boundaries, so nothing here is a surprise later.
Not every field is encrypted
Data the database has to filter, sort, or join on stays readable by design: role, clinic id, status, timestamps, assignment ids, and a non-identifying label. The guarantee covers the content that identifies a child, not the fact that a record exists or how records relate.
The server key authority is a trusted component
It brokers wrapped keys and never sees a plaintext key or any readable information. But it decides who is eligible to receive a key, so it is a part of the system you have to trust to enforce that eligibility correctly. It is a single issuance authority.
Encryption does not add privacy between staff in a clinic
The clinic key opens every child’s record in that clinic, and it is issued to each staff device that qualifies. Who can see what within a clinic is enforced by the access rules, not by the encryption. The envelope protects against outside access to raw data, not against an authorized insider whose role already grants the key.
Full key rotation and revocation are still being built
The multi-generation scheme is in place, but end-to-end rotation and re-encrypting older records are not finished. Removing a device stops it from receiving future keys; it cannot claw back data the device already decrypted. Revocation here is forward-looking.
Read auditing is not tamper-proof yet
Access rules can allow or deny a read but cannot record who read what. The app logs reads on the client as a best effort, which a modified client could skip. A complete, tamper-proof read trail needs server-side data-access logs from the cloud provider, which is the planned next step and not yet enabled.
It is in active development, not an audited product
This is a pre-release build, tested through TestFlight. We describe the design and its current state honestly. There is no SOC 2 or HITRUST certificate to point to yet, and some operational controls (breach workflow, retention schedule, enforced staff MFA) are still being built.
It is not a substitute for a signed agreement
Where the law requires a business associate agreement in the US, or a written safeguards agreement with a custodian in Ontario, that has to be executed separately. These technical controls reduce exposure; they do not replace the legal paperwork.
Some optional paths process data outside the envelope
Optional AI assistance runs on the device through Apple’s models with a child’s name withheld from prompts, and anything that would leave the device is off by default. Features like these are disclosed in the app and kept to the minimum, but they sit outside the field-encryption guarantee.
Threat model
What we defend against, and how.
Security is easier to trust when the threats are named. Here is what BrightPath is designed to withstand, stated alongside the honest gaps.
Someone obtains a raw copy of the database
The identifying fields are AES-256-GCM ciphertext on top of the cloud provider’s own at-rest encryption. Without a device-held key they cannot be read. Queryable metadata is still visible, by design.
A ciphertext is copied into a different record or field
Each envelope is bound to its scope, clinic, document, and field. Misplaced ciphertext fails to decrypt, and the rules also pin the key id to the clinic or caregiver key family.
A user tries to reach another clinic’s or another child’s records
Role-aware rules enforce same-clinic and assigned-child scope and end in default-deny. The rule suite is tested against a local emulator in CI.
A malicious sender pushes wrong key bytes to a device
Every device checks a delivered key against a write-once SHA-256 fingerprint from the registry before installing it, so tampered key material is refused.
A parent tries to get the clinic-wide key
The key authority issues a parent only the caregiver key, after confirming they are a caregiver of a child in that clinic. The rules also block client delivery of clinic keys to parents.
A child’s details leaking onto a lock screen
Push payloads carry only fixed wording and opaque ids resolved after unlock. No name, note, title, or location is ever sent.
A departed staff member’s device keeps a cached key
Role removal stops future key delivery, and the generation scheme lets a clinic rotate so a cached key opens only pre-rotation data. Rotation is forward-looking and still being rolled out.
An authorized insider over-reaching within a clinic
Limited by the access rules, not by encryption, since the clinic key opens all clinic records. Stated plainly rather than overclaimed.
Standards we build on
Not our opinion. Published practice.
Every choice here traces to documented guidance you can read yourself.
Compliance
Where BrightPath stands on compliance
BrightPath is built primarily for Ontario clinics, so PHIPA is the reference point, with the HIPAA Security Rule used as a control framework for anyone working in a US context. The technical safeguards, field-level encryption, role-based access control, and a consent lifecycle, are real and tested. The open work is operational: tamper-proof read auditing, key rotation and revocation, a breach-response workflow, a retention schedule, and enforced staff multi-factor authentication. We would rather tell you that plainly than claim a finished compliance program we do not have.
- Encrypting PHI at rest and in transit maps to the HIPAA Security Rule’s technical safeguards, and, kept properly, supports the breach-notification safe harbor for a lost or stolen device.
- PHIPA expects a written, public statement of safeguards. This page and the privacy policy are part of that.
- A clinic remains the custodian of its data. Using BrightPath does not move that responsibility, and a written safeguards agreement covers the relationship.
- No SOC 2 or HITRUST attestation is claimed. If BrightPath earns one, it will say so here with the report behind it.