[Reference] Relationship between Access Policies and Admission Rules – Cipherscale Support Center

Abstract

Understand how Access Policies and Admission Rules relate to each other. This is essential for building effective and accurate access control.

Overview

When configuring access control in Cipherscale, two key components work together to determine whether a user can access a resource: Admission Rules and Access Policies. Understanding how these two entities relate to each other is essential for building effective and accurate access control.

What is an Admission Rule?

An admission rule defines conditions that must be satisfied for an access policy to be applied. Think of it as a set of criteria that a device or connection must meet.

Admission rules support three types of conditions:

Location Context— Country or IP-based restrictions
Time Constraints— Day and time-based windows
Device Posture— OS version, encryption, antivirus, etc.

Note

An admission rule does not grant or block access on its own. It only defines when or under what conditions a policy is applied.

What is an Access Policy?

An access policy defines who can access what, and whether that access is allowed or denied. It has three core components:

Component	Description	Example
Source	Who the policy applies to	All users, HR Group,john@company.com
Destination	What resource is being accessed	HR Portal, Salesforce, Internet
Action	Whether to allow or deny access	Allow, Deny

An access policy can optionally have an admission rule assigned to it, which adds a layer of conditional logic.

The Action Field: Policy, Not Admission Rule

A common point of confusion is where the Allow/Deny action lives. The action is a property of the Access Policy, not the admission rule. This means:

The admission rule defines when the policy applies
The access policy defines what happens when it applies

This separation gives you powerful flexibility. The same admission rule can be reused across multiple policies:

Access Policy	Action	Admission Rule	Outcome
Access to HR Portal	Allow	Weekdays 9AM-5PM UTC	Access granted during business hours
Access to Finance Portal	Allow	Weekdays 9AM-5PM UTC	Access granted during business hours

How Access Policies and Admission Rules Work Together

When an admission rule is assigned to an access policy, the policy is only applied when the admission rule conditions are met. If the conditions are not met, the policy is simply skipped— as if it doesn't exist for that connection. Cipherscale then continues evaluating the remaining policies in priority order, resulting in one of the three possible outcomes below:

1. Another Policy Grants Access

If a lower-priority policy exists that also covers the same resource and its admission rule conditions are met (or it has no admission rule), access is granted.

2. Another Policy Denies Access

If a lower-priority policy exists that denies access to the same resource and its conditions are met, access is blocked.

3. No Other Policies Match — Default Deny

If no other policies cover the resource, Cipherscale applies its default behavior: deny all. The resource cannot be accessed.

Note

Cipherscale operates on a "deny unless explicitly allowed" model. If no matching Allow policy is found after evaluating all policies, access is always denied.

A Practical Example

Imagine this policy setup for the HR Portal:

Priority	Policy	Action	Admission Rule
1	HR Team Access	Allow	Weekdays 9 AM-5 PM UTC
2	(none)	—	—

Scenario: An HR team member tries to access the HR Portal on a Saturday.

Policy 1 is evaluated → Admission rule fails (it's the weekend) → Skipped
No more policies exist
Result: Access denied (default deny kicks in)

Now imagine an updated setup:

Priority	Policy	Action	Admission Rule
1	HR Team Access	Allow	Weekdays 9AM-5PM UTC
2	HR Emergency Access	Allow	No restrictions

Scenario: Same HR team member tries on a Saturday.

Policy 1 is evaluated → Admission rule fails → Skipped
Policy 2 is evaluated → No admission rule → Applied
Result: Access granted via Policy 2

Admission Rules Only Work With Allow Action

Deny policies can only use the default admission rule ("Admission without Restrictions"). Custom admission rules with time, location, or device posture conditions are only supported on Allow policies.

This means you cannot directly say"Deny access during weekends" using a custom admission rule. Instead, the recommended approach is to flip the logic:

Goal	Wrong Approach	Correct Approach
Block access during 9AM-5PM	Deny policy + time constraint rule	Allow policy + time constraint for hours outside 9AM-5PM
Block access from Russia	Deny policy + country block rule	Allow policy + country rule set to ONLY allow other countries

Key Takeaways

Admission rules and access policies are separate entities— an admission rule can exist without a policy, and a policy can exist without an admission rule
The Allow/Deny action belongs to the Access Policy, not the admission rule
Admission rules define conditions, and access policies define outcomes
One admission rule can be reused across many policies
Custom admission rules only work with Allow policies— Deny policies are unconditional by design
A policy without an admission rule uses "Admission without Restrictions" and applies unconditionally to all matching users, groups, and devices
A skipped policy has zero effect — it neither grants nor blocks access
1. Evaluation continues to the next policy in priority order after a skip
2. Default behavior is always Deny — if no matching Allow policy is found, access is blocked
3. Policy priority order matters — the order in which policies are evaluated can significantly impact access outcomes
Multiple policies can cover the same resource — this is intentional and allows for layered access control scenarios