Security overview
MDCare holds a clinic's medical device inventory, its maintenance history and the reports that prove it. That evidence is what an inspection turns on, so this page says what protects it, and - just as plainly - what does not yet.
What MDCare holds, and what it does not
The service records equipment, not patients. Devices, their locations, their manufacturers' maintenance requirements, the maintenances performed, the measurements taken and the documents uploaded as evidence. It also holds an account for each person who uses it: name, email address and role.
MDCare is not designed to process patient health data and asks for none. The one route by which such data could enter is a file a user uploads as a maintenance report. Customers should keep patient identifiers out of those files; nothing in the product needs them.
Separating one clinic from another
Every record belongs to exactly one organisation, and this is enforced twice.
In the application. Each request establishes which organisation it is acting for, and every query is filtered by it automatically. A query written without that context does not quietly return everything - it raises an error and the request fails. Tests walk the model registry, so a newly added table that is not covered breaks the build rather than shipping unprotected.
In the database. PostgreSQL row-level security policies sit underneath, on every table holding customer data, enforced for reads and for writes. They catch what the application layer by definition cannot: a raw query, a manual database session, a mistake. The application connects as an ordinary database role, never as a superuser, because a superuser bypasses these policies regardless of how they are written.
Access and authentication
- Passwords are stored as PBKDF2-SHA256 hashes with 1,000,000 iterations and a per-password salt. They are never stored or logged in a readable form, and cannot be recovered - only reset.
- New passwords are checked against length, similarity to the user's own details, and a list of common passwords.
- Three roles - user, department manager, organisation manager - determine what a signed-in person may do. Only an organisation manager can invite colleagues, change billing or alter configuration.
- Invitations and password resets use single-use, time-limited tokens sent by email.
- Sessions last fourteen days, on cookies marked Secure, HttpOnly and SameSite=Lax. Fourteen days is a deliberate choice: the product is used on a phone in a corridor, and a login prompt at every scan is a product people stop using.
Data in transit and at rest
- All traffic is HTTPS. Plain HTTP is redirected, and HSTS is sent with a one-year lifetime covering subdomains.
- Uploaded documents are stored privately and served through signed links that expire after five minutes. They are never publicly addressable, and each organisation's files are written under its own key prefix.
- Database and file storage are encrypted at rest to the standard of the hosting provider named in the subprocessor list.
Payments
Subscriptions are handled by Stripe. Card details are entered on Stripe's own page and are never received, transmitted or stored by MDCare. What we hold is the billing contact, the plan and the subscription status.
The audit trail
Creations, changes and deletions of device and maintenance records are written to an append-only trail: who, when, what changed, and the value before and after. Those entries cannot be edited or deleted through the application - the attempt is refused - because a maintenance history that can be rewritten afterwards proves nothing at an inspection.
Backups and recovery
- The database is dumped nightly, compressed and kept for a configured retention period.
- A dump that comes back implausibly small is rejected rather than stored, so a silent failure cannot quietly replace the last good backup.
- Restores are tested by actually running them, not by assuming the file is good. Restoring over a production database requires explicit confirmation.
Monitoring and change
- Liveness and readiness endpoints are probed continuously; readiness fails if the database does not answer.
- Application errors are reported to Sentry with personal data collection switched off: we receive the stack trace, not the record that triggered it.
- Changes are covered by an automated test suite that must pass before a deployment, including tests written specifically for the tenant isolation described above, at both layers.
What we do not do yet
Read this section first if you are assessing MDCare. A security page that lists only strengths tells you nothing you could not have guessed.
- No multi-factor authentication. A password is currently the only factor. This is the most significant gap on this page and the next one we intend to close.
- No lockout or rate limiting on sign-in. Password guessing is slowed by the cost of the hash, not by a limit on attempts.
- No independent certification. MDCare holds no SOC 2 report and no ISO 27001 certificate, and has not been penetration tested by a third party.
- No self-service export or erasure. A customer's data can be exported or deleted on request, by a person, within the periods set out in the processing agreement - not through a button in the product.
- No 24/7 on-call. MDCare is operated during business hours, Central European Time. There is no contractual uptime guarantee.
- Data is held in the EU, not in Switzerland. See the subprocessor list for where exactly. If Swiss residency is a requirement for your institution, tell us: the system is provider-agnostic and Swiss hosting is available, but it is not where it runs today.
Reporting something
If you believe you have found a vulnerability, write to the security contact listed below. Please give us a description and the steps to reproduce it. We will acknowledge within five working days. We will not pursue anyone who reports a finding in good faith and does not access, alter or retain another customer's data.