Security

CalibDue is a new vendor. We would rather tell you exactly what is built, what is in progress, and what is not built yet than summarise it into a badge we haven't earned. This page is that answer.

1. Data isolation

Every authenticated request is scoped to your organisation at the middleware layer — there is no cross-organisation API surface to bypass. We verified this with a 15-endpoint cross-tenant sweep across every module that produced zero leaks and zero mutations. Three roles (admin, technician, viewer) are enforced at both the route and the guard level, so a read-only account cannot reach a write endpoint even if it guesses the URL.

2. Authentication

We use cookie-based session authentication (Laravel Sanctum) rather than long-lived API tokens sitting in local storage. Signup is self-serve and public, so it is rate-limited at both ends — five attempts per email address and twenty per IP address every fifteen minutes — and a new account must verify its email address before its administrator can invite anyone else. Login, logout, password reset, password-reset requests, email verification, and invitation-acceptance are each rate-limited on their own budget. Colleagues join an existing lab by invitation only: there is no way to attach yourself to a lab you were not invited to.

3. File integrity and access

Every uploaded file — calibration certificates, controlled-document versions, EQA evidence, maintenance evidence — is stored with a SHA-256 checksum captured at upload, so tampering after the fact is detectable. Files are never served from a public URL: every download is a short-lived signed URL that expires after 15 minutes.

4. Audit trail

Destructive actions are soft-deleted, never hard-deleted from under you, and every change is written to an append-only activity log with the actor stamped server-side (not client-supplied). We call this "append-only" rather than "immutable" deliberately: the log cannot be edited through the product, but it is not yet cryptographically chained, so we are not claiming tamper-evidence we haven't built.

5. Sub-processors

We use a small, named set of infrastructure providers:

• Hostinger — our production host. This is where the application and its database run.
• Brevo — transactional email (SMTP relay) for reminders, invitations, and password resets.
• Sentry — error tracking. The SDK is integrated in the codebase; ask us for its current status in production if that matters to your assessment.
• AWS S3 — planned object storage for uploaded files. It is not in use yet: files are written to the application server's own disk. Moving them to S3 is the next infrastructure change.

6. What we do not have yet

Naming the gaps is the only credible thing an unknown vendor can do, so here is the honest list:

• No SOC 2 or ISO 27001 certification.
• No HIPAA Business Associate Agreement.
• No multi-factor authentication or single sign-on.
• Database encryption at rest is not currently enabled — it is planned but not yet turned on.
• Automated database backups are not yet running. We said previously that this would be in place before any lab's data went live, and it was not — the product opened first. We are not going to pretend otherwise: it is the single largest gap on this page, and it is what we are fixing next. If that is disqualifying for your laboratory right now, it should be.
• No self-service bulk data export today. Exports exist as PDF reports (calibration, training, maintenance, documents) and a CSV activity-log export; a full bulk export is on the roadmap.

If your procurement process needs written answers on any of this, ask — contact@calibdue.com.