IP Access Restrictions

Overview

The Delinea Platform and Secret Server Cloud (SSC) support three approaches to controlling access by source IP address. Each approach answers a different question, applies at a different layer, and has a different configuration path. Use this topic to choose the right approach for your goal, then follow the link to the configuration steps.

Note: A Web Application Firewall (WAF) is a network-edge filter that inspects and blocks traffic before it reaches the application. Tenant-wide IP restrictions in the Delinea Platform are enforced at the WAF layer.

Choose Your Approach

Match your goal to one of the three approaches in the table below.

Approach	What it does	Self-service	Platform	SSC
Policy-based restriction	Blocks specific users or groups from signing in outside allowed IP ranges.	Yes	Yes	Yes
Tenant-wide WAF allowlist	Blocks all traffic to your tenant from outside approved IP ranges. Covers both web/UI and API traffic.	No (Support ticket required)	Yes	Yes
Conditional authentication	Adjusts authentication requirements (such as requiring Multi-Factor Authentication (MFA)) based on source IP.	Yes	Yes	Handled by Platform when SSC runs on the Platform

Quick Decision Guide

Use the questions below to pick the right approach.

Block specific users from signing in outside trusted networks. Use policy-based restriction.
Block all access to the tenant from outside approved networks. Use the tenant-wide WAF allowlist.
Require stronger authentication (such as MFA) when users sign in from outside the corporate network. Use conditional authentication.

Note: You can combine approaches. The tenant-wide WAF allowlist evaluates first at the network edge. Policy-based restriction and conditional authentication evaluate after the request reaches the application.

Where to Configure Each Approach

Each approach is configured in a different topic. Follow the appropriate link below.

Policy-Based Restriction

Configure user-level or group-level IP restrictions in your authentication policies.

Delinea Platform. Define IP ranges in Corporate IP Ranges, then reference those ranges in Authentication Rules.
Secret Server (standalone SSC and on-premises). See Restricting IP Addresses in Secret Server and User Restriction Settings.

Tenant-Wide WAF Allowlist

Submit a list of approved IP addresses or CIDR ranges to Delinea Support. Support configures the allowlist at the WAF layer for your tenant. The allowlist applies to both web/UI and API traffic, because both share the same tenant hostnames (for example, <tenant>.secretservercloud.com and <tenant>.delinea.app).

Delinea Platform and SSC on the Platform. See Tenant IP Restrictions for submission requirements (maximum 110 entries, no duplicates, no Delinea-owned IPs, valid CIDR alignment).
Standalone SSC. Same Support process applies.

Conditional Authentication

Configure authentication rules that change requirements based on source IP. For example, require MFA when users sign in from outside a defined corporate IP range.

Delinea Platform. See Authentication Rules. Use Corporate IP Ranges to define the IP ranges that rules evaluate.

How the Approaches Interact

If you enable more than one approach, requests evaluate in this order:

Tenant-wide WAF allowlist (network edge). The WAF blocks any request from a non-approved IP address before the request reaches the application. Other rules never evaluate that request.
Policy-based restriction (application layer). The application blocks sign-in attempts from users or groups whose policy excludes the source IP.
Conditional authentication (application layer). The application applies rule-based requirements such as MFA based on source IP.

Warning: A tenant-wide WAF allowlist that is too narrow can block legitimate Platform-to-SSC traffic. Coordinate with Delinea Support to confirm your allowlist preserves required internal connectivity before enforcement.

Secret Server Cloud on the Delinea Platform

When SSC runs on the Delinea Platform, identity, authentication, and tenant-wide network controls move to the Platform layer. This changes which IP-restriction settings remain in scope inside Secret Server.

Tenant-wide WAF allowlist. Configured once at the Platform tenant. Applies to both the Platform and the integrated SSC instance, and covers both web/UI and API traffic.
Policy-based restriction. Legacy IP restrictions configured in Secret Server Cloud remain configurable in the Secret Server UI and continue to apply to any call to Secret Server, including vaulting operations such as retrieving or using a secret. The terms "global login restrictions" and "Web Services restrictions" do not apply in SSC-on-Platform mode —IP restrictions apply to Secret Server calls broadly. They do not restrict Platform-native actions that bypass the vault, such as launching a session with manually entered credentials.
Conditional authentication. Configure on the Platform. SSC sign-in flows inherit Platform authentication policies.

For full configuration details specific to SSC, see Restricting IP Addresses in Secret Server.

Troubleshooting

Note: For issues specific to the tenant-wide WAF allowlist — such as rejected submissions, lost access after a restriction takes effect, or Service Bus connectivity loss — see Troubleshooting. This section covers issues related to choosing or scoping an approach.

IP restrictions evaluate the egress IP address that the Platform sees — not the individual workstation IP. When users connect through a VPN, proxy, or corporate gateway, the Platform sees that network's public egress IP, not the device's internal IP. Users on the same network typically share the same egress IP and are affected by IP rules as a group.

Symptom	Likely cause	Resolution
Users cannot sign in from a known-good IP address.	The IP address is not included in the tenant-wide WAF allowlist.	Submit a Support ticket to add the IP to the allowlist. See Tenant IP Restrictions.
A user can sign in from one location but is blocked from another.	Each location has a different egress IP. The blocked location's egress IP is not included in the allowlist or policy.	Identify the egress IP for the blocked location. Add it to the tenant-wide WAF allowlist (Support ticket required) or to the relevant authentication policy. See Authentication Rules.
Platform integrations or SSC traffic fails after a tenant-wide allowlist change.	The new allowlist may exclude required internal egress IPs.	Open a Support ticket. Because both web/UI and API traffic share the same tenant hostname, a hostname-level allowlist change affects both. An asymmetric failure usually points to a client connecting from a different source IP.
An authentication policy is not enforcing the IP rule as expected.	The policy may not target the correct users or groups, the Corporate IP Range may not contain the expected IPs, or a higher-priority rule is overriding the one you expect to apply. Rules evaluate top-down within a policy.	Confirm the policy targets the correct users or groups. Verify the IP entries in Corporate IP Ranges. Review rule order in Authentication Rules.
MFA prompts continue inside the corporate network after configuring a corporate IP range.	The corporate IP range is defined but not yet referenced in an authentication rule.	Add the range to a rule in Authentication Rules.