A modern access decision is no longer simply "is the username correct?" The right decision has to consider the user's identity, the device's trust state, the location, the time, the sensitivity of the service being accessed, the MFA strength required, and the risk shifts within the session — all together.
Static rules and flat allow-lists cannot carry that complexity. Over time, every exception becomes a new rule, every application becomes a special case, and every risk signal becomes a separate checkpoint. The result is a policy pile that nobody can read end-to-end and that cannot clearly explain in audit why access was granted or denied.
Some solutions move this decision into a separate policy cloud. That makes the most critical moment of authentication dependent on an external API. When identity, MFA, service routing, and audit are scattered across different systems, the access path becomes invisible; the organization only sees the outcome, not how the decision was formed.
Conditional access, by contrast, should be a single decision engine running next to your identities and your services. Every step visible, every condition explainable, every decision auditable.
Because access security is not only about who enters, but about in which context, with what strength of verification, and on what basis access was granted.
An action flow engine that owns authentication, MFA, decisions, and routing in a single per-service definition.
An access flow chains login, MFA, decision points, switches, lockout handling, and access-granted/denied terminals. Each service declares its own flow, so a low-risk intranet app stays minimal while a privileged admin path stays strict — without forcing both into the same shape.
Switch nodes route on any variable the flow can see — session attributes, request headers, evaluated templates, upstream signals from your edge — using five matching modes (exact, prefix, suffix, contains, regex) with optional case-insensitivity. Decisions express themselves as pattern matches, not as scripts.
Geographic location, IP reputation, risk score, network zone — anything your edge can compute can be injected as a request header and read by a switch or decision point. The flow stays the source of truth, while signals from outside the gateway feed it without bringing an outside service into the auth path.
Each action evaluation — which step ran, what the input was, which branch was taken, which terminal was reached — lands in a structured audit stream. Operators replay sessions step by step, and security teams correlate access decisions with the rest of their telemetry through SIEM streaming.
The flow engine in detail, plus the policy primitives it composes from — and what is on the roadmap to extend them.
A single engine orchestrates login, multi-factor challenge, lockout handling, decision points, switch routing, and access-granted / access-denied terminals. Every step is an action with explicit transitions, so the path from anonymous request to authenticated session is one composable graph rather than scattered configuration.
Each service registers its own flow definition. A SaaS proxy might require only SSO, an internal app might add TOTP, and a production system might chain TOTP plus a fresh OTP plus an explicit decision point. Changing the policy for one service does not perturb the others.
The Switch action evaluates a configurable variable (header, session attribute, AAM template) and routes the flow to a target action by matching against an ordered list of patterns. Five matching modes — exact, prefix, suffix, contains, regex — with optional case-insensitivity cover everything from a role check to a regex match on the request path.
DecisionPoint actions split the flow into two paths based on whether a configured signal is present. Today the signal is a request header set by your edge (CDN, upstream policy module, or network gateway); the action surface keeps the flow structure stable while the underlying condition is taught to evaluate richer expressions.
Variables embedded in flow configuration — user identity, group membership, service id, environment, custom session attributes — resolve at evaluation time through the AAM template engine. The same template syntax used in branding, redirects, and error messages drives policy decisions, so operators learn one substitution language and use it everywhere.
Because MFA is an action inside the same flow, conditional access can require a second factor only on certain branches — for example, demand TOTP only when the switch detects an admin role, or chain TOTP plus a fresh OTP when the route reaches a high-sensitivity terminal. The escalation lives in the policy, not in user perception.
A native expression language is in development that lets a single policy combine identity, group, time, source IP, geographic location, and device posture into one readable rule — for example a single expression that asks "role is admin AND time is in business hours AND geographic origin is in the allowed list AND device trust is above the threshold". Today the same logic is achievable by chaining Switch and DecisionPoint actions; the DSL collapses common chains into a single expression.
Native evaluators for IP-to-geo lookup, time-of-day windows, and device trust score (through the endpoint trust manager) are on the roadmap so flows can branch on these signals without requiring the upstream to compute them first. The header-injection path stays supported for environments that already have a preferred geo or IP-reputation source.
The mechanics that make policy changes safe to deploy and easy to audit.
Each action evaluation in a flow writes a structured audit entry — action id, action type, input variables, branch chosen, terminal reached, latency. Sessions can be replayed step by step in a single timeline view rather than reconstructed from scattered logs.
Flow state lives in Redis so any gateway instance can pick up any session at any step. Horizontal scaling and zero-downtime rolling upgrades do not lose in-flight authentication state, and operators can run multiple gateway pods behind a load balancer without coordination overhead.
Failed factor attempts, rejected MFA challenges, and access-denied terminals feed the same lockout counters used by the platform's login-attack-protection layer. A user cannot brute-force a switch branch by retrying a failing factor while a parallel attempt waits at a different step.
Flow definitions live in JSON config delivered to the gateway; configuration changes can be staged, reviewed, and rolled out per environment. The combination of versioned config and per-step audit makes a question like 'why did this user get in yesterday?' answerable from a single artifact.
A graphical editor for the flow engine is in development so operators can compose access flows visually, validate transitions, and preview outcomes against synthetic users without editing JSON by hand. Until it ships, flows are defined in versioned configuration and reviewed through standard change control.
A planned dry-run mode runs a synthetic session through a flow without affecting real users, returning the action-by-action trace and final outcome. Combined with the visual builder, it turns policy changes into testable artifacts rather than blind production deployments.
The same flow engine that authenticates the user decides whether a given service requires MFA, which factor, and whether the trusted-device shortcut applies. MFA policy is not a separate product — it is one node in the access flow for that service.
Edge components (CDN, IP-reputation feeds, network gateway) inject geographic and reputation headers; the flow's switch and decision points branch on those signals — for example, denying logins from known malicious networks or routing high-risk regions through stricter MFA chains.
Switch nodes routed by user role or group membership compose access tiers in a single flow — administrators take one path with stricter MFA, regular users take a frictionless path, contractors take a third path bound by time and asset list. The flow stays auditable as one artifact.
PCI-DSS, HIPAA, ISO 27001 scoped services run their own stricter flows — mandatory MFA, mandatory recording on session start, no trusted-device shortcut. The auditor reviews one flow definition and one audit stream, not a stack of overlapping rules.
One flow engine, one source of truth, one audit stream — for every service, every step, and every decision. We'll walk through a live deployment on your applications.