Security & cryptography glossary.
Plain-language definitions of the security, authorization, and cryptography terms you’ll meet across B5 Secure — from activity-data authorization to zero trust. Built for the Never Trust model: authenticate every caller, authorize the exact action on the exact record. Bookmark it; we keep it current.
Five layers, deepest is strongest.
Every request clears each applicable layer—explicitly—before it reaches your business logic. Each stage below has a full definition in the glossary.
Activity-Data Authorization ADA · layer B5
B5 Secure’s deepest layer: an explicit permit for the exact action on the exact record, evaluated on every request rather than granted once at login. The default authorization model in B5 — little code, fully overridable.
Agentic identity
The identity of an autonomous AI agent acting on a user’s behalf. Under Never Trust it is bound to that user’s permits, scoped to the action and the record, and re-checked every call — never inherited from a standing session. Agentic identity →
Allow-list
An explicit list of permitted networks, origins, or callers; everything not on it is denied by default. The inverse of a block-list, and the safer default for sensitive keys and admin sessions.
Anti-money laundering (AML)
The regulatory regime — Bank Secrecy Act, FinCEN rules, OFAC sanctions — that obliges financial platforms to detect and report illicit activity. The examination that tests it is answered with evidence, which is where per-request decision records earn their keep.
Assume breach
A core Never Trust principle: design every endpoint as if the next caller is already an attacker, and decide accordingly.
AuthCookie
A B5 browser-session authentication scheme — scoped, revocable, and validated inside the pipeline alongside identity and origin.
Authentication
Proving who is making a request. In B5 this is layer B2, via HMAC, Service-HMAC, AuthCookie, or Service-Key. Distinct from authorization, which decides what the caller may do.
Authorization
Deciding whether an authenticated caller may perform a specific action on specific data. In B5 this is the deepest layer (B5 · ADA).
B1–B5 pipeline
B5 Secure’s five-stage Never Trust pipeline: B1 XSS screening, B2 authentication, B3 IP firewall & MFA, B4 verification & suspension, B5 activity-data authorization. Each request clears every applicable layer before reaching your logic. The security pipeline →
B5SecurityKit
The B5 Secure code library for .NET 10 (C# 14) that implements the Never Trust pipeline and ships every API surface behind it in a single host.
Bearer token
A credential where mere possession grants access — the common default in API authentication. B5 binds requests with signatures (HMAC) so a leaked token cannot be replayed against a different action or record.
CAE Continuous Access Evaluation
Revoking an identity’s access mid-session the moment a risk event occurs, rather than waiting for the next token to expire.
Cedar
An open policy language for fine-grained, policy-based authorization (PBAC). A 2026 B5 granular-authorization option behind the pipeline — ADA stays the default.
Cerbos
A decoupled authorization engine for policy-based access control. A 2026 B5 granular-authorization option reached through a standard PEP.
Confidential by default
Returning the minimum data a caller needs; widening the response requires explicit, verified privilege. The data-side complement to least privilege.
Continuous authentication
Re-verifying identity throughout a session as signals change, instead of trusting a single check at login. Continuous authentication →
Continuous authorization
Treating authorization as a property of every request, re-evaluated continuously — not a one-time grant captured at login. Continuous authorization →
Defense in depth
Layering many independent checks so no single failure grants access — the vault model B5 is named for: like the 5th basement level, every compartment carries its own independent locks.
Feature hiding
Returning “not found” or “forbidden” rather than revealing to an unauthorized caller that a feature or record even exists — denying reconnaissance as well as access.
FIDO2
A passwordless authentication standard (paired with WebAuthn) that uses public-key passkeys instead of shared secrets. A 2026 B5 multi-factor option.
FIPS 140-3
The U.S. government standard for cryptographic modules; Level 3 adds physical tamper resistance and identity-based access to keys. B5 Secure targets FIPS 140-3 Level 3 HSMs.
HMAC Hash-based Message Authentication Code
A signature computed over a request with a shared secret key. It authenticates the caller and proves the request was not tampered with — it does not encrypt the payload. A core B5 authentication scheme. HMAC →
HSM Hardware Security Module
A tamper-resistant device that generates, stores, and uses cryptographic keys so the private key material never leaves the hardware. B5 can reference HSM-held keys rather than handling raw secrets.
IP firewall layer B3
Restricting sensitive keys, admin sessions, and endpoints to known networks via an allow-list, and rejecting spoofable signals as authorization decisions. IP firewall →
Key-leakage protection
Controls that shrink the blast radius of a leaked credential — scoping, expiry, IP binding, and request signing — so a stolen key cannot be reused broadly. Key-leakage protection →
Key rotation
Periodically replacing cryptographic keys to limit exposure if one is ever compromised, without disrupting service.
Know your business (KYB)
Verification of a legal entity — formation, standing, and ultimate beneficial owners — before it may transact. The entity-side sibling of KYC.
Know your customer (KYC)
Verification of an individual’s identity and risk profile before account opening. Authentication proves who is calling now; KYC proves who they are at all.
Know your transactions (KYT)
Ongoing monitoring of transactions for suspicious patterns. Complementary to authorization: KYT asks whether activity looks wrong; authorization decides whether each action was permitted — and records why.
Least privilege
Granting only the access a given action requires, so a leaked read key can never act as an admin. Enforced per action, not per session.
Machine identity
A non-human identity — a service, job, or workload — carrying its own keys, allow-lists, and authorization, rather than a shared secret trusted because it runs inside the perimeter. Machine identity →
MFA Multi-Factor Authentication
Requiring more than one proof of identity. In B5, MFA is per-action and per-identity step-up that protects privileged endpoints without slowing everything down. MFA →
ML-DSA FIPS 204
Module-Lattice Digital Signature Algorithm — a NIST-standardized post-quantum signature scheme. A 2026 B5 request-signing option for quantum-resistant integrity.
ML-KEM FIPS 203
Module-Lattice Key-Encapsulation Mechanism — a NIST-standardized post-quantum algorithm for quantum-resistant key exchange.
Never Trust
B5 Secure’s security model: continuously verify every request and authorize the exact action on the exact record — for humans, services, and AI agents alike. The discipline behind the tagline “Never Trust™. Verify Everything.” Never Trust whitepaper →
NIST Zero Trust SP 800-207
The U.S. standard defining Zero Trust Architecture and its tenets — no implicit trust by network location, verification on every access. The 7 tenets →
Nonce
A “number used once” included in a signed request so that a captured request cannot be replayed a second time.
OpenFGA
An open-source relationship-based authorization (ReBAC) engine. A 2026 B5 granular-authorization option reached through an OpenID AuthZEN policy enforcement point.
OpenID AuthZEN
A standard authorization API between a policy enforcement point (PEP) and a decision engine. B5’s 2026 granular-authorization PEP speaks AuthZEN 1.0.
Origin restriction
Binding sensitive credentials and sessions to known origins or networks, and refusing to treat spoofable origin signals as authorization on their own.
Passkey
A FIDO2/WebAuthn public-key credential that replaces passwords — phishing-resistant because nothing reusable is ever transmitted.
PBAC Policy-Based Access Control
Authorization driven by centrally defined policies (e.g., Cedar or Rego) rather than hard-coded checks.
PEP Policy Enforcement Point
The component that intercepts a request and enforces the authorization decision returned by a policy engine. B5’s 2026 PEP speaks AuthZEN 1.0.
Perpetual KYC (pKYC)
Event-driven identity re-verification, replacing calendar reviews. The identity-side analogue of continuous, per-request authorization.
Post-quantum cryptography PQC
Algorithms designed to resist attacks from quantum computers — e.g., ML-KEM and ML-DSA. B5 Secure is post-quantum ready. Post-quantum posture →
ReBAC Relationship-Based Access Control
Authorization derived from relationships between subjects and resources (for example, “is an owner of”). OpenFGA is a common ReBAC engine.
Rego
The policy language of Open Policy Agent (OPA). A 2026 B5 option for rules-based suspension and policy-driven decisions.
Replay attack
Re-sending a previously valid request to make it take effect again. B5 prevents replay with timestamps, nonces, and request expiration. Replay & tamper protection →
RFC 9421 HTTP Message Signatures
An IETF standard for signing HTTP messages so a recipient can verify integrity and origin. A 2026 B5 HMAC-signing option.
Salt
Random data mixed into a password before hashing so that identical passwords don’t produce identical hashes — defeating precomputed-table attacks.
Service-HMAC
A B5 machine-to-machine HMAC scheme for service callers — signed, integrity-checked, and bound to a single operation. Service-HMAC →
Service-Key
A B5 machine-to-machine key scheme for service integrations — scoped and revocable. Service-Key →
SPIFFE
Secure Production Identity Framework For Everyone — a standard for issuing verifiable identities to workloads. B5 is SPIFFE-compatible.
Step-up authentication
Requiring an additional factor at the moment of a high-impact action, rather than for the whole session.
Strong password hashing
Storing passwords with a slow, salted, purpose-built hash so that a leaked credential store resists offline cracking. Password hashing →
Suspension layer B4
Stopping an unverified, expired, suspended, or risky identity inside the pipeline — before authorization is ever considered. Suspension →
Tamper protection
Detecting and rejecting requests whose contents were altered after signing — the integrity half of what HMAC and message signatures provide.
TOTP RFC 6238
Time-based One-Time Password — the rotating six-digit codes from an authenticator app. A 2026 B5 multi-factor option.
Transaction monitoring
Automated review of money movement against expected behavior. Pairs naturally with decision evidence: monitoring flags the anomaly, the authorization record proves what was actually permitted.
Verification layer B4
Confirming an identity’s status — verified, active, not expired — before authorization runs. Account verification →
WebAuthn
The browser API behind FIDO2 passkeys, enabling passwordless, phishing-resistant authentication with hardware- or platform-bound keys.
Workload identity
A first-class identity for a running workload — service, job, or container — with its own keys and authorization, never a shared secret trusted by location. Workload identity →
XSS Cross-Site Scripting · layer B1
Injecting malicious script into content that is later rendered to other users. B5’s first layer (B1) screens inbound payloads for injection before anything is processed. XSS protection →
Zero Trust
The model of never trusting by default and verifying every request regardless of network location. B5 implements it as Never Trust — authorization enforced in code, per action, per data element. Zero Trust →
Hold your API to the vault standard.
Start free, read the Never Trust whitepaper, or talk to us about securing your platform end to end.