SECURE BY DESIGN
Security Architecture Review
for Medical Devices
Find the security decisions that will become expensive later, while your architecture can still be changed. We review trust boundaries, abuse paths and blast radius with the people who build your product.
A working architecture is not automatically a secure architecture
Most teams test whether the intended workflow works. Attackers test what else the same components allow. A missing object-level authorization check, a weakly bound token or an over-privileged worker can each be a small finding in isolation, and a full compromise when chained.
The later a design flaw is found, the more expensive it becomes to fix.
What costs a whiteboard discussion during design becomes a rework sprint after implementation, and a release blocker once a pentest, audit or customer assessment finds it. Early-stage teams have the most to gain: the architecture is still cheap to change.
The purpose of the review is to find and break those attack chains while changing the design is still a small decision, not a project.
The best time is before security becomes a release blocker
Five moments where an architecture review pays for itself:
New product or major feature
Identify assets, actors and trust boundaries before implementation hardens assumptions. For early-stage teams this is the cheapest security work they will ever buy.
Architecture change
Assess a new identity provider, cloud component, integration, AI service or data flow before it ships.
Before a pentest
Remove avoidable design issues first, so paid test time goes into deep attack paths instead of documenting known weaknesses.
Before MDR or customer review
Make technical security reasoning and ownership explicit before a Notified Body or customer security team asks for it.
After a serious finding
Fix the architectural cause and reduce blast radius instead of patching one endpoint.
What your team receives
- Prioritised architecture risks and the assumptions behind them, discussed live with your team
- Pragmatic recommendations that fit the existing product and team
- A concise written summary: decisions, open questions and the next useful validation steps
The format is deliberately lightweight: a focused session of about two hours plus a short written summary, not a formal audit report or certification package.
The review is credited toward your pentest
Book a penetration test with us within 12 months of your architecture review and the full review fee is credited toward it. The early design work costs you nothing extra on the way to tested, audit-ready evidence.
How we run MDR penetration tests →Make the next architecture decision with the abuse path in view
Tell us what you are building, which decision is in motion and where the uncertainty sits. We will respond with the most useful next step, even when that is not an architecture review.
Phone
+49 221 65031192Response Time
We typically respond to all inquiries within 24 hours during business days.
Average response time: 6-12 hours
Proven in the field
This isn't theory. Below are vulnerabilities we found and responsibly disclosed in production healthcare and critical-infrastructure software.
gematik lib-vau / lib-vau-csharp
VAU Handshake Performs Only 2 of 6 Required Server-Key Checks
A missing server-authentication step in a protocol client: the class of trust-boundary design flaw an architecture review is built to catch before implementation.
gematik Authenticator
Authentication Flow Hijack
Client authentication flows in German healthcare telematics: a design assumption about who is on the other end of a channel that did not hold.
OHIF Viewer
OIDC Credential Theft via Externally Controlled URL
Published by CISA. Authentication token handling in a web-based DICOM viewer: how session and token decisions play out at the boundary between device and browser.
DCMTK storescp
OS Command Injection via Placeholder Substitution
OS command injection reachable through a trusted network interface: what happens when input crossing a trust boundary is assumed to be friendly.