🖥 Zero Trust Hospital

A major 
hospital has
reported a 
cyberattack. Patient
records may have
been exposed. Care
teams are working
through
disruption.

The cross-border
lead is mine.
The patients are
not abstractions.

Sassa. Hospital
breach. I need
your eye for
weaknesses.

For once, your
opening line
describes the job.

Consulting
 rate. As usual.

They had a firewall,
encrypted storage
and a vendor calling
everything secure.

A locked
front door is not a
personality. What
happened after
someone got
inside?

That is what we need
to establish.

I know how to
break assumptions.
Designing a hospital that
survives them needs
more people.

Fullstack
handles security
architecture.
Dr. Mochi actually
manages hospital
information.

Invite both.

Fullstack Carrot,
reporting for
root-cause duty!
I have come
as a detective!

Dr. Mochi.
Hospital 
information
management,
patient safety,
and warmed-up
hands.

Welcome.

Two
magnifying glasses.
Neither belongs
to the only actual
detective in the
room.

Mine magnifies the
attack surface!

So does your
entrance.

Q1. What is
zero trust?
And if you
say “buy this box,”
I am stealing the
box.

Good. It is not a
box. It is a strategic
commitment and
an architectural
approach.

The old mistake:
assume the inside
is safe. One stolen
login gets through
the gate, then
wanders everywhere.

A buffet 
with a
password.

Zero trust grants no
automatic trust
because you are on
the hospital
network—or using a
hospital-owned
device.

“Never trust, always
verify” means explicit,
policy-based access.
Not universal
suspicion of patients.

Authentication asks:
who are you?
Authorization
asks: may you do
this action on this
resource?

Proving you are a
doctor does not
authorize every
patient chart.

Check identity,
device health, patient
assignment, purpose,
time and risk.

Reassess access
as context changes.
Continuous
evaluation does not
mean an MFA popup
every second.

MFA = 
Multi-Factor
Authentication

Least privilege:
only the resources
and actions needed,
for only as long as
needed.

One slice. Not
ownership of
agriculture.

Assume breach. A
control may fail.
Segmentation limits
sideways movement
between systems.

A compromised
reception device
should not become a
corridor to every
clinical database.

Encryption protects
data in transit and
at rest. But an
authorized-looking
session can still
request decrypted
data.

A perfect safe is
unimpressive if you
hand the thief the
contents.

Zero Trust
Architecture covers
the whole design. Zero
Trust Network Access
is one access
technology—not the
whole strategy.

Start with an
inventory, data
flows, owners and
risk. Then phase
controls in and test
them against real
clinical work.

Q2. A patient
uploads a very
sensitive document.
Only their authorized
doctor should 
read it.

Then the 
doctor forgets
to log out
and leaves for
coffee for ten
minutes.
Simulate
that. In detail.

First, 
Mochi handles
HIPAA.
Architecture
must support the
hospital’s
obligations—
not pretend to
replace them.

HIPAA.
One P,
two As.
A U.S. law—
not a global
hospital
certification.

It applies to
covered entities,
including qualifying
healthcare providers,
and their business 
associates.

Our simulation
is a U.S. covered
hospital. Other
jurisdictions and
special record
types can add
obligations.

Three key
rule groups: 
Privacy, Security
and
Breach Notification.

Privacy
governs protected
health information—
PHI. Security
protects electronic
PHI: confidentiality,
integrity and
availability.

You learned
edible
architecture!

Administrative
safeguards: risk
analysis, accountable
staff, training, access
procedures, incident
response and
contingency
planning.

Physical
safeguards: controlled
facilities, protected
workstations, and
safe handling and
disposal of devices
and media.

Technical
safeguards
include access
controls, audit
controls, integrity
protection,
authentication and
transmission
security.

Policies, contracts,
evidence and ongoing
risk management
matter. Encryption
alone is not “HIPAA
compliance.”

The Privacy Rule
also gives patients
rights, including
access to records
and requests for
amendment, subject
to its rules.

Minimum
necessary
generally limits
many uses and
disclosures.
Disclosures
to, and requests
by, providers for
treatment are an
important
exception.

So “only
doctors,
by law” would
be a bad
summary.

Correct. HIPAA does
not ban patients,
nurses or other
properly authorized
people from records.

For this simulation,
routine staff viewing
of this document is
limited to the assigned
doctor. Patient rights
and lawful exceptions
still apply.

Do not invent
a universal HIPAA
timeout. Set session
controls through risk
analysis and
clinical workflow
assessment.

In the Security
Rule framework
described here,
automatic logoff
and encryption
specifications are
addressable.
That requires
assessment and
documentation—
not casual
omission.

A cloud provider
handling ePHI on the
hospital’s behalf
generally needs a
business associate
agreement—even if it
cannot decrypt the
data.

Assess incidents
and notification duties
promptly. For breaches
requiring individual notice:
without unreasonable
delay, no later than
60 days after
discovery.

That is an
outer
limit—not
permission
to wait.

Now a fictional
design—not a
compliance
certificate.

Patient uploads.
Assigned doctor
views. Everyone
else needs a
separate, explicit
authorization path.

Use synthetic
records for this
demonstration.
Real patients are
not our test
data.

Clients contact a
protected application
gateway. The document
API enforces policy on
every request.

An identity provider
supplies authentication.
A policy service
evaluates permissions
and context. Private
storage and a separate
key service sit behind it.

NIST separates the
policy engine, which
decides, from the
policy
administrator,
which executes the
decision.

The policy
enforcement
point—the PEP—guards
the resource and can
terminate access.
The engine and
administrator form
the policy decision point.

Upload begins with a
verified patient
account and strong
authentication.
Confirm
the account may
submit to this
patient record.

The upload
permission is
narrow: this
operation, this
destination, short
lifetime. It does
not grant read
access to other
records.

Validate file size
and allowed type;
inspect content and
scan for malware in
isolation.

Keep the document
quarantined until
checks pass. Any
preview or content
processing runs with
tightly limited
privileges.

And no sending it to
an unapproved public
AI for “helpful”
analysis.

Bind the object
server-side to the
verified patient and
sensitivity policy.
Never trust a
browser-supplied
patient ID alone.

Encrypt transport
and stored objects,
using separate
managed keys and
controlled service
identities.

Storage is
private. The
browser cannot
list it or bypass
the document
API.

The doctor signs in
using phishing-resistant
MFA where supported,
on a managed,
patched device with
endpoint protection.

Authentication gets
a session—not
unrestricted chart
access. The server still
authorizes each
document request.

Example policy:
active clinician
account AND doctor
role AND current
care assignment to
this patient.

Also require a
permitted purpose,
approved device,
acceptable risk,
valid session and
permission for this
document’s
sensitivity.

A role is one
condition.
Not a
master key.

Allow only this
document and
action. A changed
document identifier
triggers a fresh
object-level
authorization check.

A different doctor
cannot guess an ID
and inherit permission.
An admin account does
not automatically
mean clinical read
access.

Only the authorized
service path can
obtain decryption
capability. Do
not hand the browser
a reusable storage
credential.

Use short-lived, audience-
bound credentials; validate
scope, expiry and revocation.
Keep access mediated
rather than issuing long-
lived document links.

For this sensitive
workflow, restrict
exports, printing
and local caching
where practical. Record
who accessed what,
when and why—without
dumping clinical
content into logs.

You cannot
promise a
screenshot never
happens. Or stop
someone
photographing
a screen with
architecture
alone.

Exactly. Reduce
risk; do not sell
impossibility.

Here comes
the coffee. The
doctor forgets to
log out.

An open session is
an exposure.
Zero trust is not
mind-reading. It
cannot magically
identify whoever is
looking.

Example local
policy: after 60
seconds without
activity, obscure
the document and
lock the app. The
managed workstation
locks too.

This number is a
design choice for
our simulation—not a
HIPAA mandate.
Test it with care
teams and
accessibility needs.

And if someone
touches the mouse
before the timeout?

They may keep an
idle timer alive.
That is a residual
risk—not proof
the doctor is
still present.

Manual locking,
workspace controls
and privacy screens
still matter. Presence
sensing can help,
but brings its own
privacy and
reliability risks.

After ten minutes,
the doctor cannot
simply resume
reading. Unlock
requires fresh local
authentication and
renewed server-side
authorization.

Short session
lifetimes and
server-side
revocation limit
reuse. A refresh
token is not
permission to reopen
the chart forever.

Another doctor
sits down. Or the
original doctor
leaves the care
team.

Reevaluate
the actual
user and
current
assignment.
Wrong user
or expired
relationship:
deny
further
reads.

Revoke active access
promptly when policy
changes. Already
seen information
cannot be unseen.

Emergencies 
need a designed
break-glass path.
Authenticate,
record a reason,
limit access and
duration, alert
reviewers and audit
afterward.

Do not create an
unlogged universal
password. And do
not let security
design block urgent
care.

A denied routine
request stays denied
when policy cannot
be established. But
hospitals also need
tested downtime
procedures and
emergency access.

Rehearse
outages,
restoration
and
incident
containment.
Protect
evidence
 and recover
care safely
from
tested
backups.

Availability
belongs
in the
investigation
too.

Watch for unusual
bulk reads, new
devices, privilege
changes and risky
session behavior.
Alert, investigate,
and revoke or step
up authentication
when justified.

We preserve
identity, device,
policy and access
logs. We
reconstruct the
sequence before
naming a cause.

A diagram is not
evidence that this
hospital had—or
lacked—any
particular control.

The summary: verify
explicitly, grant
least privilege,
assume breach.

Make it a maintained
architecture and an
organizational
commitment.
Identity, devices,
applications, data,
people and recovery
must agree.

Do not buy a magic
carrot and call the
hospital finished.

AI raises the
stakes: convincing
impersonation,
faster abuse, and
agents that can act
across tools.

Give agents their
own scoped
identities. Enforce
permissions outside
the model, restrict
data and tool
access, and require
approval for
high-impact actions.

Treat retrieved
documents as
untrusted input.
A sentence
in a chart must
not become 
permission to
export the ward.

Do not
think
outside
the box.
First
check who
authorized
the box.

Thank you. 
Both of you.
You have given
me a way to
ask better
questions—and
protect people
while
we investigate.

Was that deep
appreciation?

Yes.
His face has
no notification
system.

A hospital
that values
protection should
fund it. Otherwise I
would steal the
budget just to prove
it existed.

Make sure
they are
paid properly.
Both experts.
And me.

Send the invoices.

Zero implicit
trust.
Explicit
payment
authorization.

Approved.