SecurisNexus | Care without blind trust

A clinician opens an imaging study. A monitoring device sends observations to a clinical system. A service engineer investigates a fault on equipment under a maintenance contract. Three requests, three different kinds of authority. None of them should inherit permission to do everything else merely because the connection originates inside the hospital.

That distinction is the practical core of Zero Trust. NIST describes an architecture that "assumes there is no implicit trust granted to assets or user accounts based solely on their physical or network location (i.e., local area networks versus the internet) or based on asset ownership," and that treats authentication and authorization as "discrete functions performed before a session to an enterprise resource is established."^[1]

For a hospital, the interesting question is not whether that principle is correct. It is what applying it costs, and who absorbs that cost. A clinician should not have to become a security specialist in order to treat a patient. An organization should not have to choose between access it cannot account for and systems its staff quietly route around.

This article describes how we are approaching that problem in the design of SecurisNexus, and — more usefully for a healthcare leader — what you should be able to demand of any system that claims to solve it, ours included. What follows is design direction rather than a description of deployed capability. Where we say the system should do something, that is the requirement we are building toward, and the evidence for it has to be produced workflow by workflow. We return to what remains unproven at the end.

Not a judgment of people

The name invites a misreading. It sounds like an instruction to treat staff as suspects, which is both insulting and operationally useless.

The real distinction is narrower and easier to defend. A hospital can trust a clinician's professional judgment completely and still limit what that clinician's account is able to do. It can trust a supplier to service equipment without granting a path to unrelated systems. It can approve an application without authorizing every use of the information that application can reach.

Authentication establishes evidence about who or what is connecting. Authorization determines which access is permitted. A successful login answers the first question. It does not settle the second for every resource and every action.^[1]

Consider the difference between reading one study and exporting several thousand records. Both can originate from the same authenticated account, on the same workstation, in the same session. They are not the same request, and a model that cannot tell them apart is not really making decisions — it is making one decision, at login, and then living with it.

This is also why Zero Trust should never become a reason to defer more basic work. The HHS Healthcare and Public Health Cybersecurity Performance Goals — which the department describes as voluntary — cover multifactor authentication, vulnerability mitigation, and basic incident planning as essential goals, with asset inventory, network segmentation, and centralized log collection as enhanced ones.^[2] An access model belongs alongside that foundation, not in place of it.

One request

Take the clinician opening a patient's imaging study from a shared workstation. What follows is an illustration of the design, not an account of a deployed environment.

It helps to name the stages a single request passes through:

Request → Identity → Authentication → Device Evaluation → Context Evaluation → Intent Evaluation → Policy Decision → Microsegmented Access → Continuous Verification → Audit Trail

Six stages left to right: Request, Identity, Device, Decision, Enforcement, Audit, each with the question it settles — One request, followed end to end. Each stage answers one question and leaves a record; none of them is “trusted”.

This is a teaching sequence, not a NIST framework and not a fixed order every application must execute. Some evidence will already exist from a valid session. Some checks repeat. And audit evidence should be produced throughout — including for denials, failures, and revocations, not only for successes.

Establish the actor, and keep it attached

First, identify both the clinician and the software making the request on their behalf. A workstation's identity should not stand in for the person using it, and an application acting for a clinician should not disappear behind a shared service account that obscures who initiated the work.

Then establish sufficient authentication evidence. A recent, adequately protected session might satisfy the hospital's policy for opening a study; a more consequential action might require more. The design should not generate prompts merely to demonstrate that security exists.

The principle underneath is simple: know who is acting, keep the authority being exercised attached to that actor, and never hand over more authority than the task requires.

SecurisNexus identities screen labeled demo data: one workload, Desktop viewer, and one user, Alex Demo, listed as separate identities — A person and a workload, kept as separate identities. The badge on the screen says demo data. This is the design surface, not a clinic’s directory, and not a deployed access decision.

Four boxes: certificate derives an identity token, which derives a grant token, both presented to an enforcement point that checks they name the same subject — Authentication is by certificate. Authority is a separate, signed grant. The enforcement point checks both, and the scope, every time.

Terminal output: a request with no client certificate is cut at the handshake with code 000; no login page, no error to enumerate — Without an identity the handshake is cut: no login page, nothing to enumerate.

Terminal output: the same request with an issued certificate is answered with code 200 — With an issued identity, the same service answers. Test run, 21 September 2026.

Evaluate the device and the circumstances

NIST's implementation guidance describes access decisions drawing on relatively stable information — identity, role — alongside changing context such as device health and resource sensitivity.^[3]

For the imaging request, a hospital might weigh whether the workstation is managed, whether its security information is recent enough to mean anything, and whether the clinician has a defensible reason to open this particular study. A care relationship can be a useful input. It should not harden into a universal rule that blocks legitimate consultations, emergency care, or separately authorized organizational work — a policy that only anticipates the assigned-patient case will fail the first time a colleague is asked for a second opinion.

Missing evidence deserves a deliberate answer. If device information is stale, the system should not silently read "unknown" as "healthy." It might require an additional verification step, narrow the permitted operation, or route the clinician to an approved alternative. Which response is right is a decision for clinical and operational owners, not something a risk score should improvise.

Decide what action is actually authorized

The next question is not whether the clinician can reach the imaging application. It is what they are asking to do there.

"Intent" here means the requested operation and its declared purpose — opening a study for a consultation — evaluated against policy and available evidence. It does not mean software reading a person's mind, and a stated purpose is evidence to weigh, not proof of anything.

Policy might permit viewing the study while requiring separate authority for bulk export or administrative changes, or require an additional approval for one particular operation where the workflow can absorb it.

The output of that decision needs to be more useful than a label like "trusted." It should name the permitted action, the resource, the duration, and the conditions. Clinical, security, privacy, and operational owners agree those rules between them. No software component should be inventing them on their behalf.

SecurisNexus policy details screen labeled demo data, for the read-only policy demo-read: verdict Allowed, action data.read, resource vault:demo/, subject user:demo — One policy row names the verdict, the action, the resource, and the subject. The values are demo data. The article is the requirement this screen is being built toward.

Terminal output: a grant for one read on one resource, and an access check on that resource returning allowed true — Allowed for the one thing the token was minted for.

Terminal output: the same token used for a different resource returns allowed false, grant does not cover requested action, resource, or scope — Refused for the next thing over, with the same token. Test run, 21 September 2026.

Enforce the boundary where the action happens

Network segmentation restricts which systems can talk to each other. It is not a decision about which records a user may read or change. NIST's guidance for cloud-native environments makes the same point from the other direction, describing policies based on "application and service identities in addition to the underlying network parameters and user identities" in order to enforce granular application-level policy.^[4]

The imaging example needs both: a restricted path to the necessary service, and application-level permission for the specific authorized operation. A network rule is not evidence that an application enforced a record-level restriction.

This is where integration stops being a detail. A policy cannot make an application read-only unless something in the path can actually prevent a write. Any honest implementation has to state what it controls, where, and which paths remain outside that control.

Two rows: a control-plane administrator token reading one patient record is refused with 403 and recorded; the allowed clinician reading the same record gets 200 — Being the administrator of the control plane is not a clinical identity. The refusal is recorded at the edge. Test run, 21 September 2026.

Revisit access when its basis changes

Permission should not become permanent simply because it was appropriate when the session opened. NIST's findings describe builds in which sessions in progress "are periodically reevaluated by reauthenticating the identities of the requesting user and the requesting endpoint and by verifying the health of the requesting endpoint," and in which "if these periodic reauthentications and verifications cannot be performed successfully, the access session will eventually be terminated."^[5]

Those same findings are candid about the limits: in the builds described, the identity and health of the resource-hosting endpoints were not verified over the life of the session.^[5] That is a useful reminder that continuous verification describes a discipline, not a guarantee that every condition is known at every instant.

A hospital should therefore decide in advance which changes trigger re-evaluation and what happens next — a session ending, a delegation expiring, security evidence changing — and match the response to the action and its safety implications rather than dropping everything associated with an account. The design also has to account for the time it takes information to reach an enforcement point, and to distinguish clearly between stopping further access and recovering data already disclosed. Revocation does the first. Nothing does the second.

Sequence diagram across owner, control plane, and audit store: a signed flow grant is recorded; the same grant widened to another port is refused with 403 because its signature does not verify; the grant is revoked; a replay of the original is refused with 409 and stays revoked — Access that was granted can be withdrawn, and the record shows it: a widened copy fails its signature, and a replay after revocation is refused. Live test through the control plane, 28 September 2026; the agent that enforces grants on the wire is not running yet.

Preserve an explanation, not just a login event

Our design requirement for SecurisNexus is that the request, the authority relied on, the policy decision, the enforcement result, and the outcome remain connected as one attributable record — covering reads and writes, approvals and denials, delegated actions, failures, and permission changes alike.

For the imaging example, a reviewer should be able to establish which actor requested which study, what authority and policy supported the decision, and whether the operation actually succeeded. A grant on its own is not evidence that the application honored it.

None of this requires copying the clinical record into a security log. It requires capturing enough to explain the event while limiting sensitive content and protecting the audit system itself. Integrity and completeness are also different properties, and worth separating in any claim: showing that a recorded event has not been altered says nothing about whether an event was missed.

Probe output showing audit counts of 7 writes allowed, 2 writes denied, 9 reads allowed, 3 reads denied, beside a small bar chart of the same four counts, and a second block showing that no data moves while the audit service is down — Grants and refusals both reach the audit store, and nothing moves while the audit store is down. A refusal that leaves no record is not a control. Counts from one test run, 21 September 2026.

Availability is part of the design

An access policy is unfinished until it says what happens when normal operation is impossible. The HHS goals treat safe response, restoration, and recovery as essential rather than optional.^[2]

Emergency access should be a defined workflow — a responsible actor, bounded authority, an attributable record, and review afterward. Its purpose is to make justified access possible when ordinary permissions do not fit the situation, not to suspend accountability for the duration.

It also cannot assume an urgent decision can wait for an approver who is unreachable at 3 a.m. Which emergency paths are acceptable, how they behave, and when review happens are questions to settle in advance, with the people responsible for care delivery in the room.

The same reasoning applies when a central identity, policy, or logging service cannot be reached. For availability-sensitive workflows the requirement is an approved downtime path with local evidence capture and later reconciliation. Losing a central collector should mean neither "stop all care" nor "record nothing." Any locally available permission should be bounded in scope and duration, with explicit limits on what may continue — and none of it should be described as resilience until the workflow has actually been tested under failure.

Devices and vendors

Return to the other two requests. A device transmitting observations and an engineer investigating a fault need nothing like the clinician's authority.

For the device, policy might permit one specific flow to its intended service without creating a route to anything else. For the engineer, it might permit a named maintenance operation on identified equipment inside an approved support window, with both the sponsoring organization and the individual recorded.

These cases also expose a real limit. Many devices and applications cannot supply strong identity evidence or fine-grained controls at all. Where a gateway stands in front of such a device, the gateway's identity is not proof of the device's integrity, and a hospital needs to know precisely what that gateway can enforce and what it cannot see.

The honest response is to document those gaps and consider compensating controls around the workflow — not to relabel an unsupported device as trustworthy. And it is worth stating plainly: decisions affecting the safe operation of clinically essential equipment belong in a validated clinical and engineering process. An access system should not be disconnecting life-supporting equipment on its own initiative.

Authority, not just instructions

An AI assistant is another actor in the same model, and it should be governed by the same questions rather than a new vocabulary.

This is an area where the standards work is genuinely early. In February 2026 NIST's NCCoE published a concept paper, Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization, seeking comment on whether to launch a full project on applying identity and authorization standards to software and AI agents. The comment period closed in April 2026.^[6] That is an open exploration of the problem — not a finished standard, and not a validation of anyone's agent architecture.

Consider an assistant asked to prepare a patient communication. It might receive permission to retrieve specified information and produce a draft. Sending the message, altering a clinical record, or passing information to another service are separate actions requiring separate authorization. Permission to draft is not permission to send.

The assistant should hold its own identity, with its actions traceable to the person or organization that delegated the task. A broad instruction like "help with this patient's care" should never function as a general-purpose credential.

Most importantly, the model should not be the final judge of whether its own tool calls are permitted. An enforcement component outside the model should check each action against explicit policy and the limits of the delegation. Instructions to behave safely are a useful complement to that boundary and a poor substitute for it.

Consent and permission also need to be represented accurately rather than collapsed into a single checkbox. An employee's permission to use an assistant does not by itself authorize every disclosure that assistant might propose, and patient consent, organizational permission, and legal basis remain distinct questions.

Finally, correct authorization says nothing about clinical correctness. A permitted draft can still be wrong. Access control, clinical validation, and human responsibility are different parts of the problem, and a strong identity does not make a model's output reliable.

Where it fits

The opportunity we see is not to redefine Zero Trust. NIST's implementation guide, finalized in June 2025, already documents example architectures built from commercial products across nineteen builds.^[7] Its findings also describe a coordination problem worth dwelling on: policies "are not centrally located," being configured and managed alongside each policy decision point, which "makes it challenging to understand, articulate, and manage the ZTA's policies as a comprehensive whole" — and those components "do not typically integrate with each other to share information."^[5]

That gap is where we are aiming. The role we intend for SecurisNexus is to connect identity, organizational authority, scoped permissions, delegation, and audit evidence across selected workflows, so that an understandable authorization decision can travel from the request to the component that actually performs the action.

It does not replace an electronic health record, endpoint protection, device monitoring, a firewall, an existing identity provider, backups, or clinical governance. It creates an integration requirement: those systems have to exchange enough evidence and enforce the agreed boundaries.

These are architectural goals. Each supported workflow still needs its own evidence — what is enforced, how permissions expire or are revoked, what happens during failure, and which events the audit path actually captures. Demonstrating one workflow would not establish coverage across a hospital, and we would rather say that plainly than let a demonstration imply more than it shows. It is the same scrutiny we would ask you to apply to anyone else.

Swimlane diagram with five lanes, iPad, SecurisNexus, session host, patient VM, audit, and nine numbered steps from discovery to the audit record — Nine steps, eight controls, five layers, for one request. Every hop is checked by the layer that owns it.

Start with one workflow

If this is worth acting on, the first step is not a platform decision. Choose one bounded workflow — third-party maintenance access is a good candidate, because its boundaries are already contractual — and map it end to end: the people and systems involved, the actions they genuinely need, the enforcement points that already exist, and the exceptions required to keep the service usable.

Then test the boundaries rather than the login. Does access actually stop when the authorized window closes? Can the account reach something unrelated? What happens when evidence is missing? Can you reconstruct both a permitted action and a denied one, months later, for someone who was not there?

Clinical access deserves the same treatment with more attention to workflow and downtime safety, and it needs clinical operations, IT, security, privacy, and biomedical engineering in the same conversation. Where those groups disagree, the disagreement is the design input. It is not a detail to be settled later by a product.

Measure both control and usability, or the program will optimize for the half you measure: how much standing access has been removed, how reliably policy changes reach enforcement points, whether the evidence is complete, how quickly legitimate work proceeds, and how often valid requests are wrongly blocked.

The goal was never to make a hospital trust no one. It is to stop its safety from depending on trust that is broader, longer-lived, or less accountable than the work actually requires.

So the question worth putting to any vendor, and to your own teams, is not "do we have Zero Trust?" It is this: can we show who is allowed to do what, under which conditions — and can the people delivering care still do their jobs when those conditions change?

That is the standard we want SecurisNexus to help make practical.

A table of nine zero-trust checks, each marked PASS: certificate and chain present, anonymous mTLS denied, certificate answered with 200, a scope refusal after the full chain, default deny on the web console, audit log present, LAN address unreachable — Start with one workflow and check it nine ways. Four of the nine pass by refusing. Test run on our own systems, September 2026.

← Back to Blog

Start with one workflow. We can help.

The article asks you to demand evidence rather than promises; we hold ourselves to the same standard. SecurisNexus is the access model this piece describes, not a product we install for you today. What we can do now is help you choose a bounded workflow, map it, and test its boundaries — the services below are how that work gets done.

Network and remote-access monitoring — see every device and every vendor or IT login on your clinical network, with a record you can reconstruct months later. Observation only; we never block care.
Security testing & assessment — test the boundaries, not the login: does access stop when the window closes? Can the account reach something unrelated? Reports written for auditors and insurers.
Medical device security — assess the devices on your network and document what a gateway can and cannot enforce. Manufacturers preparing an FDA submission can start with our 524B evidence checklist.
AI systems before clinical use — review an assistant’s permissions, delegation, and behavior under pressure before it touches patient data.
Security training — role-based sessions for clinicians, biomed, and IT, tied to issues we actually see — risk reduction, not compliance theater.

Request a scoping call

Or write to josh@vivasecuris.com.

References

NIST Special Publication 800-207, Zero Trust Architecture, August 2020. https://csrc.nist.gov/pubs/sp/800/207/final
U.S. Department of Health and Human Services, Healthcare and Public Health Cybersecurity Performance Goals (voluntary). https://hhscyber.hhs.gov/cybersecurity-performance-goals.html
NIST Special Publication 1800-35, Implementing a Zero Trust Architecture, Volume A: Project Overview, final, June 2025. https://pages.nist.gov/zero-trust-architecture/VolumeA/ProjectOverview.html
NIST Special Publication 800-207A, A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Cloud Environments, September 2023. https://csrc.nist.gov/pubs/sp/800/207/a/final
NIST Special Publication 1800-35, Implementing a Zero Trust Architecture, Volume B: General Findings, final, June 2025. https://pages.nist.gov/zero-trust-architecture/VolumeB/GeneralFindings.html
NIST National Cybersecurity Center of Excellence, [Concept Paper] Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization, February 5, 2026; comment period closed April 2, 2026. https://csrc.nist.gov/pubs/other/2026/02/05/accelerating-the-adoption-of-software-and-ai-agent/ipd
NIST Special Publication 1800-35, Implementing a Zero Trust Architecture, final, June 2025. https://pages.nist.gov/zero-trust-architecture/