Login and Access Restrictions

Overview

You can limit which networks and mobile platforms users sign in to the Delinea Platform from, and how long their sessions last. Use this topic to choose the right control and find where to configure it.

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.

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.

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.

How the Approaches Interact

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

  1. 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.
  2. Policy-based restriction (application layer). The application blocks sign-in attempts from users or groups whose policy excludes the source IP.
  3. 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.

Blocking Mobile Devices with an Authentication Rule

You can restrict sign-ins from mobile platforms with an identity policy authentication rule that uses the Device operating system condition, such as iOS or Android. See Authentication Rules.

An operating system restriction applies to any client that presents as that operating system, however the user authenticates. That includes the Delinea mobile apps and mobile browsers on those devices.

Note: The rule applies only to users and groups the identity policy is assigned to. Test the policy with a small group before you assign it widely.

Blocking Mobile Devices at the Identity Provider

If your users sign in through a federated identity provider (IdP), you can also use the IdP's authentication policy to block sign-ins from mobile platforms. For example, create a policy that denies access when the client platform is iOS or Android.

When the IdP blocks a mobile platform, it blocks sign-ins from both the Delinea mobile apps, such as the Credentials and Platform Mobile apps, and mobile browsers on that platform. Sign-ins from desktop browsers aren't affected.

Note: The steps depend on your IdP. See your IdP's documentation for authentication policy conditions based on the client platform.

Limiting Session Length

Identity policies also control how long users stay signed in. Shorter sessions reduce how long an unattended or lost device keeps access.

  • Browser sessions. Set the User Idle Timeout (1 to 720 minutes, default 15). If you allow Keep me logged in, also set its session length (1 to 24 hours, default 12). See Browser Session Parameters.
  • Mobile app sessions. Set the mobile app Session Length (Days) (1 to 90 days, default 14). When the session length is reached, users must authenticate again. See Mobile Session App Parameters.

Note: Mobile Session App Parameters are not available in FedRAMP-compliant tenants.

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.

Related Topics