1. Why state must gate authorization

An identity can be perfectly authenticated and still have no business proceeding — it may be unverified, suspended, or expired. B4 evaluates lifecycle state before authorization runs, so a permit is never even considered for an identity that should not be active. Checking at request time means a status change is enforced on the very next call rather than waiting for a credential to lapse.

2. Verified, suspended, expired

Three conditions stop a request here: an identity that has not completed verification, one that has been suspended, and one whose access window has expired. Each is deny-by-default — the absence of a clean, current “active” state is itself grounds for denial. This keeps half-onboarded and stale identities out of the authorization path entirely.

3. Hierarchy-aware exclusion

Suspension follows the org and account hierarchy: suspending a parent entity reaches the identities and sub-entities beneath it, with explicit exclusion rules where a child must remain active. This is the lifecycle foundation that the policy-driven suspension and CAE extension later makes continuous — same model, evaluated in near-real-time on risk events.

4. The calling convention

State evaluation is part of the pipeline, ordered before authorization.

// B4 — lifecycle state gate, ahead of authorization
services.AddB5SecurityKit(o => {
  o.Lifecycle.RequireVerified = true;
  o.Lifecycle.Suspension      = SuspendPolicy.HierarchyAware;
  o.Lifecycle.CheckAt         = Evaluate.EveryRequest; // not at token expiry
});

5. What an attacker actually gets

A freshly suspended account is stopped on its next request, not whenever its session would have ended; a never-verified identity that obtained a credential cannot use it; an expired access window closes on schedule. When a parent is suspended, an attacker cannot pivot to a dependent identity to stay in — the hierarchy carries the denial down.

6. Where this lands in an audit

B4 is the evidence for identity lifecycle management and timely de-provisioning (NIST CSF PR.AA; SOC 2 CC6.2, CC6.3; ISO 27001 A.5.18, A.8.2). Reviewers asking “how fast does a revocation take effect?” get a concrete answer: the next request.

Next: B5 · Activity-Data Authorization — the deepest layer →