Do you really want to give a vendor the keys to all your pathology data?

Most digital-pathology platforms want you to hand over a key to your data. You are being asked to extend a remarkable amount of trust. Typically this involves handing out access credentials for an IAM user or granting broad permissions to an IAM role.

You are trusting that the vendor’s secrets manager is configured correctly today and will still be configured correctly six months from now. That no engineer at the vendor will ever screenshot, paste into a debugging Slack channel, or accidentally commit your credentials to a git repository. That when an employee leaves the vendor, or a contractor’s machine is stolen, your credentials will be rotated before anything goes wrong.

None of this is typically said out loud. Most of the time this trust is expected.

This is the quiet trust assumption at the heart of most digital-pathology procurement: the vendor reaches your storage under one identity it controls — whether that identity is a long-lived access key or a role it assumes via a trust policy you wrote — and the only thing standing between your S3 bucket and a bad day is the vendor’s security posture.

For 15 years it was the only option on offer. In 2026 it isn’t, and the 2024–2026 healthcare breach wave makes the cost of the old default concrete. Black Kite’s Sixth Annual Third-Party Breach Report (February 2025) found 41.2% of all 2024 third-party data breaches landed in healthcare. Vercel (April 2026) and — just two weeks ago — Braintrust (May 2026) are two recent SaaS breaches where customer credentials living inside the vendor’s infrastructure ended up inside the blast radius. The pattern is simple: a credential you hand a vendor today is a credential their next attacker reaches.

Cytario takes a different approach. You keep the bucket. You keep the permissions. You keep the audit trail. Every read of your storage carries the identity of the actual user — not a shared vendor identity.

Of course, there’s still a trust relationship with cytario. What changes is who controls the authorization gate, where the audit lives, and how much reach a single compromise gives the attacker.

How it works

Two models for the same problem:

Today’s default. When you log into a digital pathology platform, the platform’s server fetches your slide from your storage on your behalf. The image bytes flow through the vendor’s server. Your storage sees the vendor’s service account on every read, not the person who actually opened the slide.

Cytario’s model. When you log into cytario, the viewer in your browser fetches the slide directly from your storage without data passing through our backend. To do that, your viewer receives temporary credentials from our backend that are unique to you and scoped to the data you are accessing.

The diagram makes the contrast concrete:

The flow, step by step

This pattern works against AWS S3, MinIO, RustFS, Ceph, or any S3-compatible object store that exposes an STS-style web-identity endpoint. The rest of this section uses AWS terminology because it’s the most widely recognised — the same flow runs against open-source backends without modification, and the policy shape is identical.

1. The user authenticates via OIDC against the identity provider configured for the deployment (cytario’s Keycloak for SaaS deployments, or a customer-operated IdP for self-hosted). The cytario backend handles the OAuth 2.0 Authorization Code Flow with PKCE; the ID token is delivered to and stays on the backend. The browser only ever holds an opaque, server-signed session cookie.
2. The cytario backend, holding the ID token in its server-side session store, calls the storage backend’s STS endpoint (AssumeRoleWithWebIdentity on AWS; the same call shape on MinIO and RustFS) and exchanges the token for short-lived credentials scoped to the user’s role and groups.
3. STS validates the token against the OIDC provider the customer registered in their account, checks the role’s trust policy, and returns the temporary credentials. The backend caches them per user and refreshes them on a 5-minute buffer before expiry.
4. When the viewer needs to read tiles, the backend ships those short-lived credentials to the browser. The browser signs object-storage requests (SigV4) with the credentials and reads tiles directly from the customer’s bucket. No cytario server sits in the image data path, and no ID token ever leaves the backend.

The result, in plain language: only people in the right group at your organisation can open this viewer. You control permissions in your storage account; the audit lives in your storage backend’s log (CloudTrail on AWS, the audit endpoint on MinIO, equivalent on RustFS). Cytario operates the viewer between them.

What changes for the customer

Four concrete differences, in this order.

Authorization stays with you

The permissions that control access to your storage live in your storage account, not ours. You write them. You can scope them per user or per group by writing conditions on OIDC claims — for example, only tokens whose groups claim contains /customer/pathologists/* may assume this role. The vendor cannot grant itself permissions it doesn’t already have, and the vendor cannot bypass the conditions you wrote.

This is what an external-IAM-role trust relationship cannot give you. When a vendor’s AWS account is trusted to assume your role, the vendor decides which of its services and which of its users get what — you cede that control at the moment you grant the permission to the vendor. With OIDC federation, the authorization decision happens at every assume call, evaluated against the user’s claims, in your account.

The blast radius of a vendor compromise shrinks accordingly: a compromised user session reaches only what that user’s scoped policy allows, not the union of everything a vendor service principal could ever do.

Your storage audit log shows real users

Every cytario-mediated S3 read is attributed in your storage audit log to a specific user identity via the RoleSessionName field. When your compliance team needs to answer who looked at Patient X’s slides last Tuesday, they answer from their own logs. No support ticket.

Image data doesn’t traverse our backend

Whole-slide images stream directly from your storage to the viewer in the user’s browser. Image metadata follows the same path, and annotations (a planned addition) will too.

The cytario backend’s role is narrow: manage connections and call your storage backend’s STS endpoint to mint per-user temporary credentials. Keeping the OIDC ID token server-side is the point — the browser only ever holds short-lived storage credentials and an opaque session cookie.

What you still trust cytario for

No model eliminates trust in the vendor completely. With cytario you still rely on us to operate the OIDC issuer correctly: the signing key must be protected, the session-management code must not leak temporary credentials, and the viewer code must not exfiltrate slide data.

The architectural argument isn’t that these risks vanish, but that they are reduced and control is increased. Customers can take back control of the authorization gate and the audit trail while the blast-radius in case of a breach is reduced.

Standards alignment

This pattern is what the standards already describe as state of the art.

• HIPAA Security Rule §164.312(a)(2)(i) — unique user identification — and §164.312(b) — audit controls are much easier to demonstrate at the storage layer when using federated identities.
• GDPR Article 32 — security of processing proportionate to risk, applying state-of-the-art measures.
• AWS Well-Architected Framework, Security Pillar, SEC02-BP02 — “Use temporary credentials”: AWS classifies the risk of not using temporary credentials as high.

While using cytario does not automatically make you compliant with these standards, it gets you significantly closer.

Bottom Line

The architectural choice described here isn’t innovative in 2026 — it’s overdue. AWS recommends it. NIST describes it. The EU MDR implicitly requires it as state of the art. The 2024–2026 healthcare breach wave made the cost of the alternative concrete in dollars and in patient records.

For clinical-trial imaging in particular, identity-linked audit is what your regulatory-affairs team will need to demonstrate under the upcoming HIPAA Security Rule update and the ICH E6(R3) data-integrity guidance — both of which expect attributable, user-level access records rather than vendor-aggregated logs.

Cytario is open-source. The credential flow described here is in our code, not just in this blog post — you can audit it before you trust it.

Have questions about implementing a secure digital pathology infrastructure? Get in touch with us – we’d love to discuss your specific needs and how cytario can help you reduce costs while securing your operations.

Further Resources