Zero Trust that stays inside your boundary — no gateway, no sidecar, no sub-processor.
NIST defines Zero Trust as continuous, per-request verification with no implicit trust. Most implementations decide at a policy decision point and assume something downstream enforces. B5 Secure is that enforcement — the in-process Policy Enforcement Point for the .NET application tier, where Never Trust is the verb form of continuous authority.
Every Zero Trust reference architecture has a Policy Enforcement Point. Most leave it to hand-written code.
NIST SP 800-207 separates the Policy Decision Point (which decides) from the Policy Enforcement Point (which permits or blocks the action). The market is rich in decision points — control planes, gateways, external authorization engines. The enforcement point, the place that actually stops an out-of-scope action inside the application, is usually code the customer writes by hand. That is the weakest link in most Zero Trust deployments, and exactly where B5 lives.
Trust the network
- Verify at the perimeter, trust within
- PDP decides; enforcement assumed downstream
- Enforcement is hand-written, drifting application code
- A new gateway or sidecar to operate and secure
Enforce every request
- Verify every request, trust nothing implicitly
- PEP enforces the decision at the call site
- Enforcement is a declarative [Permission] primitive
- A library — no gateway, no sidecar, no new endpoint
B5 is the Policy Enforcement Point that compiles into your application.
Keep your decision points and detection. B5 makes their decisions binding at the method — the last and most important point in any Zero Trust architecture.
In-process PEP
Authorization is enforced where the action executes, not at an edge the action runs past. There is no decision-then-forgot-to-enforce gap.
Deny by default
Absence of evidence means absence of access. Every request earns its access through the full pipeline; no internal-only exemptions or undocumented switches.
Least privilege at the credential
Scope every credential to the action and record it serves, so a leaked key opens a few endpoints, not the whole platform.
Continuous verification
Per-action evaluation with live risk signals, not a one-time perimeter check — the core of the NIST model.
The ultimate deploy-anywhere
A library runs wherever your code runs, including air-gapped and on-prem regulated environments — no cloud-only dependency.
Continuous logging and detection
Every request is logged at the execution point; replay, credential abuse, and anomalies surface in the signals you are already watching.
Zero Trust, enforced in the application tier.
On-prem and air-gapped
A library is the ultimate deploy-anywhere — Zero Trust enforcement with no external service to reach.
Native, not foreign
Idiomatic ASP.NET Core middleware and attributes, not a generic proxy bolted onto .NET.
PEP for Entra decisions
Entra Conditional Access decides; B5 is the in-app enforcement point those decisions land on.
B5 is the enforcement point, not the whole Zero Trust program.
Co-exists with your PDP and detection layers.
Zero Trust is an architecture, not a product, and B5 does not claim to be the entire program. B5 is the in-process PEP for the .NET tier — it co-exists with Entra, SPIFFE, and a Tier-1 control plane, consuming their decisions and risk signals and making them binding at the method. For .NET-centric or air-gapped shops it is also a lighter path that avoids standing up a gateway.
Zero Trust that stays inside your boundary.
See how B5 becomes the Policy Enforcement Point in your Zero Trust architecture — with no gateway, no sidecar, and no new sub-processor.