“Zero Trust” has been worn thin by marketing, but it has a precise, vendor-neutral definition. In 2020 NIST published Special Publication 800-207, Zero Trust Architecture, and distilled the model into seven tenets. They are not a product checklist; they are design principles. Read them as an engineer and one idea runs through all seven: stop trusting the network, and verify every request against live context, every time. B5 Secure is that idea turned into a request pipeline — “Never Trust” is SP 800-207 made executable. Here is each tenet in plain terms, and what it asks of your code.

1. Every data source and service is a resource

NIST treats everything that holds or serves data as a protected resource — not just servers, but APIs, functions, queues, and individual records. In practice you stop reasoning in terms of “inside the firewall” and start protecting each endpoint and each object on its own merits. B5’s activity-data authorization (ADA) takes this to its logical end: a decision is made not only for the operation but for the specific record and fields it touches.

2. All communication is secured, regardless of location

Sitting on the corporate network grants no trust. Every exchange is encrypted and authenticated whether it crosses the public internet or a private subnet. In code that means TLS everywhere and request-level authentication that does not depend on where the caller sits. B5 signs every request with keyed HMAC over the canonical message — method, URL, body, timestamp and nonce — so a private network is never a substitute for a verified signature.

3. Access is granted per session

Trust is evaluated for a single session or transaction and never assumed to carry over. The practical translation is least privilege, short-lived credentials, and re-evaluation rather than a standing grant. B5 binds each signed request to one operation and one record, with a short expiry window and a nonce to defeat replay — access is earned per request, not issued once and reused.

4. Access is determined by dynamic policy

The decision factors in identity, the state of the requesting asset, and behavioral or environmental attributes — resolved at runtime, not baked into a role at deploy time. The cleanest way to honor this is to treat policy as data evaluated by an engine, not as if statements scattered through controllers. B5’s pipeline composes identity, MFA state and network context into the decision today; the 2026 track externalizes it to standards such as AuthZEN and OpenFGA so policy lives outside — and outlives — the code.

5. Posture of every asset is continuously measured

No asset is inherently trusted; its integrity and security posture are monitored and fed back into access decisions. A device or session whose posture degrades should see its access narrow automatically. B5’s suspension stage is the enforcement point for this: you can revoke a user, or a single operation on a single entity, the moment a KYC, fraud or risk signal demands it — without a deploy.

6. Authentication and authorization are dynamic and strictly enforced

Verification happens before every access and is enforced continuously — which, stated plainly, means fail closed. If a check cannot complete, the answer is deny. This is B5’s defining property: the pipeline fails closed by default, so a request that does not fully authenticate and authorize never reaches your handler. Security is the default state, not something you remember to add.

7. Collect telemetry, and use it to get harder

An enterprise gathers as much data as it can about the state of its assets, network and communications, and uses it to improve posture over time. In practice: log every decision, make it auditable, and feed it back. B5 emits events and hooks at every stage, so each decision is observable and auditable — the raw material for incident response and for the continuous access evaluation (CAE) in the 2026 extensions.