ASD ISM 2136Enforcing Risk-Based Access Decisions Informed by Contextual Signals
Access to systems and their resources is granted, stepped up or denied according to the risk of each request, judged from signals such as the user, device, location and behaviour.
Plain language
A valid username, password and second factor prove that someone holds the right credentials. They do not prove that the request is safe. A login from a brand-new device in a country the user has never visited, at three in the morning, a few seconds after a login from the office, looks very different from the same user's normal Monday sign-in, even though both present the same credentials. This control requires that access to systems and their resources is decided on risk, not just on credentials, and that those decisions are enforced rather than merely reported. The decision is informed by contextual signals: things like who is asking, what device they are on and whether it is managed and healthy, where the request comes from, when it happens, what resource is being requested and how sensitive it is, and whether the pattern of activity matches what is normal for that user. Low-risk requests proceed. Higher-risk requests are challenged with stronger authentication, limited to a reduced level of access, or blocked outright. It matters because most successful intrusions use legitimate credentials that have been phished, guessed, reused or bought. Static access rules treat a stolen credential exactly like the rightful owner. Risk-based decisions give the system a way to notice that something about the request does not fit, and to act on it before the attacker reaches the resource. The statement applies to access to both systems and the resources within them, so the same thinking covers the initial sign-in and the subsequent requests for applications, data and administrative functions.
Framework
ASD Information Security Manual (ISM)
Control effect
Preventative
Classifications
NC, OS, P, S, TS
ISM last updated
Sept 2026
Control Stack last updated
05 Sept 2026
E8 maturity levels
N/A
Guideline
Guidelines for system accessTopic
Authenticating to systems
Official control statement
Risk-based access decisions, informed by contextual signals, are enforced for access to systems and their resources.
Why it matters
Without risk-based access decisions, every request that carries valid credentials is treated identically, regardless of how anomalous it is. An attacker who phishes a password and defeats or bypasses the second factor, hijacks a session token, or uses a compromised device gains the same access as the legitimate user, from anywhere, at any time, to any resource that user can reach. Contextual signals that would have flagged the request (unfamiliar device, impossible travel, unmanaged or non-compliant endpoint, unusual resource) are either not collected or not acted upon, so the intrusion proceeds silently until it is discovered by other means. The organisation also loses the ability to apply stronger protection to sensitive systems and resources without imposing that friction on every routine request, which in practice pushes it towards weaker blanket settings. The likely outcomes are account takeover, lateral movement into higher-value systems, data theft and administrative compromise that could have been challenged or stopped at the point of access.
Operational notes
Day to day, this control lives in the policy engine of the identity provider, access gateway or zero trust platform that sits in front of systems and their resources. Someone owns the policy set: which signals are collected, how they combine into a risk assessment, and which outcomes (allow, step-up authentication, restricted access, deny) apply at each level, including stricter thresholds for sensitive resources and privileged access.
Signals only work if they are fed. Device posture depends on endpoint management and health attestation reporting into the policy engine; behavioural signals depend on identity and sign-in telemetry; resource sensitivity depends on systems and data being classified and tagged. Operations teams need to watch that these feeds stay connected, because a broken feed quietly turns a risk-based decision into a static one.
Expect tuning. New policies are usually run in report-only mode first to see what they would have blocked, then enforced. False positives (staff travelling, new device rollouts, network changes) generate help desk tickets and need a clear path for users to re-establish trust, such as verifying on a known device, without opening a bypass that an attacker could use. Denied and stepped-up decisions should feed security monitoring, since a burst of high-risk decisions for one account is often the first sign of a credential compromise. Policies and thresholds should be reviewed when new systems or resources are onboarded, when threat intelligence changes, and after any incident where a risky request was allowed.
Implementation tips
- Identity and access owners define the risk model in writing: list the contextual signals available (user identity and role, device identity and compliance state, network location, time, requested resource and its sensitivity, sign-in and behavioural anomalies), describe how they combine into risk levels, and map each level to an enforced outcome (allow, step-up authentication, reduced access, deny).
- Platform engineers connect every signal source to the policy engine: enrol endpoints in device management so posture and compliance are reported, integrate identity protection or user and entity behaviour analytics for anomaly detection, and tag systems and resources with sensitivity so the engine knows what is being requested.
- Security architects route access to systems and their resources through an enforcement point that can act on the decision, such as the identity provider's conditional access, a zero trust access gateway or an application proxy, rather than relying on individual applications to interpret risk on their own.
- Identity administrators build the policies in the engine and deploy them in report-only mode first, review what each policy would have challenged or blocked over a few weeks, adjust thresholds and exceptions, then switch the policies to enforced, applying the strictest outcomes to privileged access and highly sensitive resources.
- Security operations and the help desk set up the run-state processes: forward risk decisions and denials to the SIEM with alerting on repeated high-risk events per account, publish a user re-verification path for legitimate blocked access, and schedule a periodic review of policies, signal feed health and exception lists with the policy owner.
Audit / evidence tips
- AskAsk for the documented risk-based access policy or design that describes which contextual signals are used and how they drive access decisions.Look atCheck that it names concrete signals (user, device state, location, time, resource sensitivity, behaviour), explains how they are combined into risk levels, and states the enforced outcome for each level.GoodA current, owned document that maps specific signals to specific outcomes such as allow, step-up, restrict or deny, and that covers access to resources within systems as well as initial sign-in.
- AskAsk to see the live policy configuration in the identity provider, access gateway or zero trust platform that enforces these decisions.Look atConfirm the policies are in enforced mode rather than report-only, that they apply to the in-scope systems and resources, and that stricter rules cover privileged access and sensitive resources.GoodEnforced policies whose scope matches the documented design, with no broad exclusion groups or legacy authentication paths that let requests bypass the risk assessment.
- AskAsk for evidence that the contextual signal feeds are actually connected and healthy, such as device compliance reporting, identity risk detection and resource classification.Look atLook at integration status, the proportion of devices reporting posture, and whether risk detections are populating in the console.GoodAll signal sources the design relies on are integrated and reporting for the great majority of users and devices, with a monitoring check that flags when a feed stops.
- AskAsk for sign-in and access logs showing decisions over a recent period, including examples that were challenged or denied.Look atLook for records that show the signals evaluated, the risk level reached and the outcome applied, and check that high-risk requests were actually stepped up or blocked rather than only logged.GoodLogs that demonstrate the policy working in practice, with a mix of allowed, challenged and denied requests, and that show the rationale for each decision.
- AskAsk how blocked or challenged users are handled and how the policies are reviewed and tuned over time.Look atLook at the help desk re-verification procedure, records of policy changes, exception lists with justification and expiry, and any review after incidents or new system onboarding.GoodA defined re-verification path that does not simply disable the policy, a change history showing periodic tuning, and exceptions that are limited, justified and time-bound.
Cross-framework mappings
How ISM-2136 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
sync_altPartially overlaps(1)expand_less | ||
| Annex A 5.18 | ISM-2136 requires enforcing access decisions per request based on contextual signals and risk, including granting, stepping up, or denyin... | |
handshakeSupports(3)expand_less | ||
| Annex A 5.15 | ISM-2136 requires enforcing risk-based access decisions using contextual signals (e.g | |
| Annex A 5.16 | ISM-2136 requires enforcing risk-based access decisions using contextual signals tied to users and their access requests | |
| Annex A 8.3 | ISM-2136 requires dynamic enforcement of access decisions driven by contextual risk signals at the time of each access request | |
extensionDepends on(1)expand_less | ||
| Annex A 5.17 | ISM-2136 requires enforcing risk-based access decisions that may step up authentication or deny access based on contextual risk | |
E8
| Control | Notes | Details |
|---|---|---|
sync_altPartially overlaps(1)expand_less | ||
| E8-RA-ML1.1 | ISM-2136 requires enforcing risk-based access decisions using contextual signals to allow, step up, or deny access to systems and resources | |
handshakeSupports(2)expand_less | ||
| E8-MF-ML1.3 | ISM-2136 requires risk-based access decisions informed by contextual signals, including stepping up authentication when risk is higher | |
| E8-RA-ML3.3 | ISM-2136 requires enforcing contextual, risk-based access decisions that can step up controls or deny access depending on the request con... | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.
Related ASD ISM controls in System access
See all Guidelines for system access controls, or browse the full ASD ISM library.