Trust
Encryption
Encryption is the security claim most often inflated and most easily checked, which is a bad combination for a vendor and a useful one for you. This page draws the lines exactly: what the platform underneath us provides, what we build ourselves, and what we do not have. The third list is the shortest and the most important.
- Quality and compliance
- Hospital operations
- Clinical engineering
What is encrypted in Rydya?
Definition
Encryption in Rydya
Traffic is encrypted in transit with TLS; the database and object storage are encrypted at rest by the hosted platform Rydya runs on; and exactly one thing is encrypted by Rydya itself at the application layer, which is the secret used to sign outbound webhooks.
That last clause is the one most vendors would leave out, and it is the reason this page is worth reading. Application-level encryption is where a product actually makes choices. Everything else on the list is a property of infrastructure we buy, and describing it as our security engineering would be taking credit for a provider's datasheet.
The distinction matters practically, not just morally. When your security reviewer asks who holds the keys, the answer for at-rest encryption is our hosting platform, and that has consequences for your risk assessment that a paragraph about AES-256 would obscure.
What is encrypted, by whom, and with what
Read the third column carefully. It is where the real answer lives.
| Layer | Status | Who provides it |
|---|---|---|
| Traffic to the API | TLS | Standard HTTPS. Termination and HSTS are edge configuration at deployment. |
| Traffic to the database | TLS, enforced | Ours. Disabling it is flagged as unsafe by our environment validator. |
| Database at rest | Encrypted | The hosted platform. A provider property, not Rydya engineering. |
| Object storage at rest | Encrypted | The hosted platform. Same caveat. |
| Webhook signing secrets | AES-256-GCM | Ours. The only thing Rydya encrypts at the application layer. |
| Service-account credentials | Hashed, not encrypted | Ours. SHA-256 of a high-entropy random token, compared in constant time. |
| Key management system | None | We do not have one. See below. |
| Per-organisation data keys | Not built | Envelope encryption is described in our architecture docs and does not exist. |
| Encrypted local storage on devices | Not built | An open decision. Offline queues are not separately encrypted by us. |
Encryption by layer, and who is accountable for it
Why we are telling you our own documentation is wrong
Because you would find it, and a false encryption claim discredits every true claim standing next to it.
Our internal architecture document describes envelope encryption with per-organisation data keys wrapped by a platform key management system, and credential hashing with argon2id. It reads well. It is also a description of a system we did not build. The reality is that the webhook secret key is a single environment variable, hashed with SHA-256 to derive the encryption key, with a development fallback that must be replaced before production. Credential hashes are SHA-256, and no argon2 or bcrypt dependency exists anywhere in our codebase.
We found this while auditing what we could honestly publish, and the temptation was obvious: the document is internal, the marketing page could have quoted it, and almost nobody would check. Diligence reviewers check encryption first, precisely because it is the claim most often inflated. A vendor caught overstating encryption does not get a note in the report; they get every other claim re-read with suspicion, which is the correct response.
On SHA-256 for credentials: it is defensible for a 192-bit random token, where the threat model that argon2id defends against, offline brute force of a human-chosen secret, does not apply. That is a real argument and we would make it. What we will not do is let a document claim argon2id while the code does something else and call the difference a detail.
How the one thing we do encrypt actually works
Webhook signing secrets, AES-256-GCM, with a real limitation stated.
Encrypted at rest with AES-256-GCM
The secret you use to verify our webhook signatures is stored encrypted rather than in plaintext, so a database read alone does not yield the ability to forge our signatures.
Shown once, then only a hint
The plaintext is returned exactly once at creation. Afterwards only a hash and a last-four hint exist. Lost means rotated, not recovered, which is the only version of this that is honestly true.
If the secret cannot be decrypted, the webhook is skipped
Rather than sent unsigned. This is the right failure direction: a receiver that cannot verify a payload should never receive one that looks verifiable.
The key is one environment variable, and that is the limitation
Derived by SHA-256 from a single configured value, with no key management system, no rotation automation and no per-organisation separation. Setting it strongly in production is a deployment gate. This is adequate for what it protects and it is not what our architecture document describes.
The question your reviewer should ask, and our answer
Ask who holds the keys to the at-rest encryption. Our honest answer: the hosted platform we run on does, and that is a property of the provider rather than of our engineering. We do not operate a key management system and we do not perform envelope encryption. If your risk assessment requires customer-managed keys or a documented KMS, we do not meet that bar today, and it is better established now than in a security questionnaire at contract stage.
When this is adequate, and when it is not
It is adequate for an organisation whose threat model is ordinary, and inadequate for one that requires customer-managed keys, and only you can say which you are.
The reason this page is not simply an apology is the invariant underneath it: Rydya stores no patient clinical records at all. The data at risk is operational and financial, staff identities, uploaded evidence, and contact details from login-free fault reports. That is real data deserving real protection, and it is a materially smaller exposure than a system holding clinical records, which changes what proportionate protection looks like.
What we are not going to do is use that invariant to wave away a requirement you actually have. If your organisation mandates customer-managed encryption keys, or a documented key management system, or encrypted local storage on field devices, Rydya does not meet those today. Those are three specific, checkable gaps rather than a general weakness, and asking us about them in week one costs you nothing.
Questions
Is our data encrypted at rest?
Yes, by the hosted platform Rydya runs on, for both the database and object storage. That is a property of our provider rather than of our engineering, and we would rather say so than let a paragraph about AES-256 imply we built it. When your reviewer asks who holds the keys, the answer is the hosting platform, and that has consequences for your risk assessment.
Do you use a key management system or envelope encryption?
No to both. Our internal architecture document describes envelope encryption with per-organisation keys wrapped by a platform KMS, and that system was never built. The reality is a single environment variable, SHA-256 derived, protecting webhook signing secrets. We are telling you this because a diligence reviewer checks encryption claims first, and a false one discredits every true claim beside it.
What does Rydya actually encrypt itself?
One thing: the secret used to sign outbound webhooks, with AES-256-GCM. It is shown once at creation and only a hash and a last-four hint are kept afterwards, so a lost secret is rotated rather than recovered. If the secret cannot be decrypted the webhook is skipped rather than sent unsigned, which is the correct failure direction.
Can we use our own encryption keys?
No. There is no customer-managed key support and no key management system. If your risk assessment requires either, Rydya does not meet that bar today. It is a specific, checkable gap rather than a general weakness, and establishing it in week one costs you nothing compared with finding it in a security questionnaire at contract stage.
See it on your equipment
Live in an afternoon, useful the same week. A person replies, usually within one working day.
Contact us