Zero Trust, Explained

The network is not a safe place. It never was. Here is what to do about it — and how SecurisNexus does it.

The perimeter model failed

For thirty years, network security worked like a castle. You built a wall, you put a gate in it, and you decided that everything inside the wall was friendly. Firewalls, VPNs, and network zones all share that assumption: location implies trust. If you are on the inside, you are trusted.

That assumption breaks the moment anything gets inside — and something always does. A phished credential. A contractor's laptop. A vendor's remote-support tool. An unpatchable device with a decade-old operating system. Once an attacker is inside the wall, the flat, trusting interior is not a defense. It is an accelerant.

How it actually goes

It rarely looks like an attack at the start. A scheduling clerk gets a message that looks like a password reset from the records vendor, and types their credentials into a convincing copy of the login page. Nothing breaks. No alarm sounds. The attacker now holds a working account and a VPN on which to use it.

From there the network does most of the work. The VPN delivers them onto a flat clinical segment, because fully segmenting a hospital network is a project almost nobody has finished. They look around. They find an ultrasound cart running an operating system that left support years ago, because the manufacturer will not certify a patched version. They find a workstation with a vendor service account whose password appears in an installation manual — the same password that vendor uses at every site it supports. That account has administrative rights, because it needed them once during commissioning and nobody narrowed it afterwards.

Weeks pass before anyone notices. By then the intruder has been through imaging, scheduling, and the share where backup indexes live. And when the incident team finally asks the only question that matters — what did they actually touch? — nobody can answer it. The logs live on the same machines that were compromised, and anything holding administrative rights can rewrite them.

No step in that story required a sophisticated exploit. Every step used the network exactly as it was designed to be used. That is the point: the perimeter model did not fail because it was implemented badly. It failed because it was implemented correctly, and its central assumption is wrong.

Four assumptions did the damage:

Trust by location

Being on the network is treated as proof of belonging. It proves only that you found a way in.

Lateral movement

One compromised host can reach everything its network segment can reach. Blast radius is the whole zone.

Shared secrets

Static passwords and long-lived API keys get copied, reused, committed to repositories, and never expire.

No provable record

Logs can be edited or deleted. After an incident, you cannot prove what happened — only assert it.

Why it is still built this way

Not because anyone believes it is safe. The perimeter was a sound design when everything it protected sat in one building, on cables the organisation owned, used by people it employed. That building dissolved. Clinicians work from home, devices phone home to manufacturers, vendors support equipment remotely, and workloads moved to somebody else's datacentre — but the security model stayed where it was.

Replacing it is genuinely hard, and in medicine it is harder than anywhere else. Re-segmenting a live clinical network is a project with real patient-safety risk, an unglamorous budget line, and no visible reward when it works. Devices cannot simply be upgraded out of the problem. And every control that can interrupt care will eventually be switched off by someone who is right to switch it off, because the patient in front of them outranks the policy.

So the honest framing is not that hospitals have been careless. It is that they are running a model built for a world that no longer exists, and that the usual remedies are unavailable to them. Any approach worth proposing has to start there.

What zero trust actually means

Zero trust is not a product you install. It is a design rule: never infer trust from position on a network. Every request — from a person, a service, a device — must prove who it is and be authorized for that specific action, every time. Nothing is trusted because of where it sits.

  • Identity is the perimeter. The unit of trust is a cryptographic identity, not an IP address, subnet, or VLAN.
  • Verify explicitly, every time. Authentication is per-request, not per-session-forever. Both sides prove who they are.
  • Least privilege, narrowly scoped. Access is granted to one resource for one purpose for a short time — not to a zone indefinitely.
  • Default deny. Absence of an explicit allow is a denial. Fail closed, not open.
  • Assume breach. Design as though an attacker is already inside, because eventually they are. Contain instead of hoping to exclude.

The practical test: if an attacker obtained a foothold on your network right now, how much would that actually get them? Under the perimeter model, often everything. Under zero trust, one narrowly-scoped identity and a permanent record of what it touched.

How SecurisNexus implements it

SecurisNexus is the identity, policy, and evidence authority for the VivaOS platform. It answers three questions continuously: who is this, what may they do, and what actually happened.

1

Every workload gets an identity

Services, devices, agents, and people each receive their own short-lived X.509 certificate carrying a SPIFFE-style identifier. Identity is issued, attested, and expiring — not a password someone can copy. There is no shared service account to steal.

2

A layered certificate authority

Trust descends through a hierarchy: a root that stays offline and archived after issuance, an intermediate that signs per-tenant authorities, and leaf certificates issued to individual workloads. Compromising a leaf does not compromise the tenant. The root is not reachable from the network at all.

3

Mutual TLS, not just TLS

Ordinary HTTPS proves the server is genuine. On the authorization and policy hops, both ends present certificates and both verify the other: a caller without a valid issued identity cannot complete the handshake, and is refused before any request is processed. The certificate bootstrap service is the exception — it uses server-TLS with token authentication.

4

Tiered, time-boxed authorization

Identifying yourself earns the right to ask. An authorization decision earns narrow access to one specific resource, for a short window, scoped to the exact caller. Everything else stays closed by default. Access expires on its own rather than relying on someone to revoke it.

5

Policy that fails closed

Authorization rules are signed configuration evaluated by the control plane. If no rule permits an action, it is denied — including when policy is missing, unreadable, or malformed. Misconfiguration produces a refusal, never accidental permission.

6

Evidence you can prove

Issuance, session, decision, and denial events are appended to a hash-chained ledger with Merkle inclusion proofs. Any single event can be cryptographically proven to be in the record, and the record cannot be altered after the fact without detection. This is the property people usually reach for a blockchain to get — without needing a distributed consensus network.

Why this matters most in medicine

Clinical environments are where conventional security breaks hardest, because the usual remedies are unavailable. You cannot reboot an infusion pump mid-therapy. You cannot force a password rotation during a code. You cannot patch a twelve-year-old imaging device whose vendor certification would be voided by the update. And when security tools get in the way of care, staff route around them — correctly, because the patient comes first.

Availability outranks policy

Care cannot pause for security. Controls that can block a clinical workflow are controls that will be disabled or bypassed.

Patching is often impossible

Long device lifecycles and regulatory certification mean "just update it" frequently is not an option. Security has to work around that, not require it.

Vendor access is routine

Outside technicians connect to devices regularly, often after hours, frequently unobserved. Identity and a durable record matter more here than anywhere.

Evidence is now required

Regulators increasingly expect device makers and providers to produce real technical evidence, not attestations. A provable record is the deliverable.

Our design rule: observe before enforcing. Security that becomes a patient-safety risk has already failed, so we begin passively — establishing identity, context, and evidence — and never insert ourselves as a new way for care to break.

What zero trust is not

  • Not a VPN. A VPN moves the wall; it still grants network-level trust once you are through it.
  • Not a firewall product. Firewalls filter addresses and ports. Zero trust decides about identities and actions.
  • Not a blockchain. Tamper-evidence comes from hash chaining and Merkle proofs. No distributed ledger, no consensus network, no token.
  • Not a single purchase. It is an architecture. Anything sold as "zero trust in a box" is a component at best.
  • Not friction for its own sake. Done properly it removes shared passwords and standing access, which is usually less friction, not more.

Security should be like a spoon

Obvious in purpose, requiring no training, and never in the way of the task. The strongest security is the kind nobody has to think about — identity that issues itself, access that expires on its own, and a record that can be proven rather than asserted.

Get in touch