Conditional access cannot be managed with a flat allow-list
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.
How we approach it
An action flow engine that owns authentication, MFA, decisions, and routing in a single per-service definition.
Every service runs its own access flow
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.
Pattern-based branching on any variable
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.
Upstream context plugs into the flow
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.
Every transition is in the audit log
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.
Capabilities
The flow engine in detail, plus the policy primitives it composes from.
Action flow engine — one chain for auth, MFA, decision, and routing
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.
Per-service flow definition
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.
Switch — pattern-matched routing on any variable
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.
Decision points for yes/no branching
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.
AAM template variables in conditions
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.
Step-up and chained MFA driven by the flow
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.
Operational depth
The mechanics that make policy changes safe to deploy and easy to audit.
Per-step audit with input and outcome
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.
Stateless flow execution coordinated through Redis
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.
Coordinated lockout across the flow
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.
Versioned flow configuration
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.
Where teams use it
Per-service MFA enforcement
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.
Geo and IP-reputation aware access
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.
Role and group-driven branching
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.
Compliance-scoped access paths
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.
Common questions
How is a conditional access policy defined today?
How are conditions like geographic location, time, and device posture evaluated?
Does the Switch action support regex matching?
How is every access decision audited?
Can a policy change be tested before it goes live?
Put your access policy back in one engine
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.