Skip to main content

Risk-Adaptive Dynamic Access Control (RADAC)

Summary​

Risk-Adaptive Dynamic Access Control (RADAC) is an authorization model that adjusts access decisions based on real-time risk factor scores. Instead of relying on static rules alone, RADAC policies define risk factors with minimum and maximum thresholds. The platform evaluates incoming risk signals against these thresholds to produce GRANT or DENY decisions. When risk signals change — a new device, an unusual location, an abnormal access pattern — RADAC policies respond by tightening or relaxing access without requiring policy modifications.

Why It Exists​

Static authorization rules cannot respond to changing threat conditions. A user who legitimately holds the "administrator" role poses a different risk when logging in from their usual office workstation versus an unrecognized device in a different country. RADAC addresses this by incorporating risk signals into authorization decisions, enabling the platform to deny or restrict access when risk indicators exceed acceptable levels — even when the user's role-based permissions would otherwise grant access.

Where It Fits in Keymate​

RADAC operates within the authorization model as one of the supported policy types. The policy evaluation engine evaluates RADAC policies using risk context assembled from the request. Risk factors can compose with other models through PBAC — for example, requiring both a valid role (RBAC) and acceptable risk (RADAC). The authentication layer can feed authentication-time risk signals (device fingerprint, login location) into the evaluation context.

Boundaries​

This page covers the RADAC authorization model. It does not cover:

How It Works​

Risk Factors​

A RADAC policy defines one or more risk factors. Each factor represents a measurable risk signal with a numeric score. Common risk factors include:

  • Device trust — whether the requesting device is recognized, registered, or unknown
  • Location risk — whether the request originates from an expected geographic area
  • Behavior pattern — whether the access pattern matches the user's historical behavior
  • Authentication strength — the level of identity verification completed during authentication
  • Time-based risk — whether the request occurs during expected operating hours

Threshold Evaluation​

Each risk factor in a RADAC policy specifies minimum and maximum score thresholds. The platform evaluates the current risk score for each factor against its thresholds:

  • If the risk score falls within the acceptable range (between minimum and maximum), the factor passes
  • If the risk score falls outside the range, the factor fails

When all factors pass, the RADAC policy returns GRANT. If any factor fails, the policy returns DENY. This threshold-based model enables fine-grained risk tolerance per policy.

Risk Context Assembly​

The platform assembles risk context from multiple sources before RADAC evaluation:

  1. Request attributes — IP address, user agent, request time, geographic location derived from the request
  2. Session attributes — device information, authentication method, session age from the current session
  3. Historical context — comparison with the user's established access patterns
  4. External signals — risk scores from external threat intelligence or fraud detection systems, when integrated

The assembled risk context provides the numeric scores that RADAC policies evaluate against their thresholds.

Dynamic Response​

RADAC policies respond dynamically to changing conditions without administrative intervention:

  • When a user accesses from a trusted device during business hours, risk scores remain within thresholds, and access is granted
  • When the same user accesses from an unrecognized device at an unusual time, risk scores shift outside thresholds, and access is denied
  • The user does not need different roles or permissions — the same RADAC policy adapts its decision based on the current risk context

Composition with Other Models​

RADAC policies gain their full power when composed with other models through PBAC:

  • RBAC + RADAC — require both a valid role and acceptable risk. This prevents compromised credentials from granting access when risk indicators are elevated.
  • ABAC + RADAC — combine attribute conditions with risk thresholds for layered context-aware authorization.
  • The decision strategy (Affirmative, Unanimous, Consensus) determines how RADAC outcomes combine with other policy outcomes.

Diagram​

Example Scenario​

Scenario​

An administrative API protects sensitive operations with a RADAC policy defining two risk factors: device trust (threshold range 70-100) and location risk (threshold range 0-30). An administrator accesses the API from an unrecognized device in an expected location.

Input​

  • Actor: Administrator with valid role assignments
  • Resource: Administrative API for user management
  • Action: Modify user account
  • Context: Device trust score: 20 (unrecognized device, below minimum 70). Location risk score: 15 (expected location, within range 0-30). RADAC policy with Unanimous evaluation.

Expected Outcome​

  • Denied — The location risk factor passes (score 15 is within the 0-30 range), but the device trust factor fails (score 20 is below the minimum threshold of 70). With all factors required to pass, the RADAC policy denies access.
  • Why: RADAC evaluates each factor against its thresholds independently. A single factor failure produces a DENY, protecting against access from untrusted devices even when the user's location is expected.

Common Misunderstandings​

  • "RADAC replaces role-based authorization" — No. RADAC complements role-based checks by adding risk awareness. A user still needs appropriate roles; RADAC adds an additional layer that evaluates contextual risk.

  • "Risk scores are binary (trusted/untrusted)" — No. Risk factors use numeric scores with configurable threshold ranges. This enables fine-grained risk tolerance rather than binary decisions.

  • "RADAC policies require an external risk scoring system" — The platform can assemble risk context from request and session attributes without external integrations. External risk scoring systems enhance the context but are not mandatory.

warning

Set RADAC thresholds conservatively during initial deployment. Overly permissive thresholds reduce RADAC's protective value, while overly strict thresholds may block legitimate access. Monitor deny rates and adjust thresholds based on observed patterns.

Design Notes / Best Practices​

  • Define risk factors that correspond to measurable, reliable signals. A device trust score based on device registration provides consistent results; a score based on subjective "suspicion" does not.
  • Compose RADAC with RBAC through PBAC for defense in depth. Role checks establish baseline access rights; RADAC adjusts decisions based on contextual risk.
  • Use RADAC for high-value resources (administrative APIs, financial transactions) where contextual risk matters most. Applying RADAC to every resource adds evaluation overhead without proportional security benefit.
tip

When onboarding RADAC policies, start with a monitoring mode that logs RADAC decisions without enforcing them. Review the logs to validate threshold calibration before switching to enforcement mode.

  • Blocking administrative access from unrecognized devices
  • Restricting financial transactions when location risk indicators are elevated
  • Requiring stronger authentication when behavior patterns deviate from the norm
  • Combining role-based access with risk-adaptive controls for sensitive operations

Authorization Model

Multi-model framework and decision strategies

ABAC

Attribute-based conditions that complement risk factors

PBAC

Composing RADAC with other models

MFA & Step-Up Authentication

Step-up authentication triggered by risk signals