How should an enterprise software startup design admin security policies, such as IP allowlists and session limits, so an admin cannot lock the whole company out?

Illustrative situation: a startup sells invoice-approval software to mid-size companies. On Friday afternoon, the security admin at a freight customer turns on an IP allowlist containing the head-office range. The page saves it without a warning. On Monday, the finance team working from home, the warehouse tablets on mobile data and the nightly integration job are all refused. The only admin who can undo it is on a train. The scene is invented. It shows the mistake this guide helps avoid: a policy page where saving and enforcing are one click.

Humbleteam, a digital product design agency, publishes this guide. It covers policy order, lockout prevention, recovery, session limits, re-authentication, tokens and apps, the audit trail and the copy for each state, with a decision table and an invented worked example. Sources and product behavior are described as of November 9, 2026 and can change. This is not security advice or an audit: your security team and your customers’ security teams decide what policy requires.

In what order should the console evaluate policies?

An admin needs to know which rule wins. In Microsoft Entra, all applicable Conditional Access policies must be satisfied, and a block control stops enforcement at once. Okta rejects addresses on a blocklisted network zone before any policy evaluation, and the client sees a 403 error. GitHub’s allow list applies to every role, owners included.

Our suggestion: show four layers in a fixed order: who the policy covers, where they connect from, how long a session lasts and how strong the sign-in must be. Put blocks above requirements and say so on the page. Add a “why was this person refused?” view that names the rule.

How do you stop an admin from locking the company out?

Five safeguards, in the order the admin meets them.

1. Preview before enforcing. GitHub lets an owner check whether a given address would be allowed even when the list is off. Entra’s report-only mode evaluates a policy at sign-in without enforcing it. It cannot judge steps that need the user, such as an MFA challenge. Our suggestion: replay the last 30 days of sign-ins against the draft and list the people it would refuse.
2. Name who is cut off. GitHub advises notifying people before it requires two-factor authentication. Outside collaborators without it are removed and can be reinstated within three months. The page describes no full list of affected people, so that screen is yours to build: “76 of 240 people would be refused. Show them.”
3. Check the admin’s own address. GitHub requires the owner to add their current address or a matching range before enabling. Our suggestion: block the save when the admin’s address falls outside the new list, unless they confirm.
4. Keep a door the rules cannot close. Atlassian’s administration site stays reachable from outside an allowlist. Entra recommends two or more emergency accounts, excluded from policies that block sign-in, validated at least every 90 days, with an alert on every use. GitHub and Okta both advise more than one owner or Super Admin.
5. Add a grace period. No source we read prescribes one. Ours: a seven-day warn-only mode, then enforcement with a 15-minute “keep this change?” prompt that rolls back if nobody answers.

What if the break-glass account fails too?

Design recovery before the outage. Okta says its support cannot create administrators, so the second Super Admin is the safeguard. Google proves domain ownership with a DNS record. The support reference goes to an address other than the locked account, DNS changes can take up to 24 hours, and the self-service flow fails if the record is not found within 48 hours.

Our suggestion: when an admin turns a policy on, ask for two recovery contacts and name the proof. Then fix the steps: verify the domain record, wait 24 hours, email every admin and contact during the wait, lift only the IP rule and log each step. Show the delay on the screen. It is slow, and a finance team will feel it.

How long should a session last?

Use two clocks. OWASP says sessions should have both an idle timeout and an absolute timeout, and the idle check belongs on the server. It gives 2-5 minutes idle for high-value applications, 15-30 minutes for low-risk ones and 4-8 hours absolute for an office worker. NIST SP 800-63B-4 says reauthentication should come within 24 hours at AAL2, with inactivity at most 1 hour. AAL3 is tighter: 12 hours overall and 15 minutes idle. These limits target federal systems, so for a commercial product they are a reference point.

Vendors differ on defaults and coverage:

• Atlassian: the idle default is 30 days, mobile app sessions are not covered, and a saved change applies at the next login.
• Google: the web session default is 14 days. Admin console sessions are fixed at one hour, and native mobile apps are not covered.
• Slack: desktop and mobile are separate settings. Desktop members can get warnings two hours and 15 minutes ahead, and a change ends sessions at random times across the chosen window.

Our design rules: separate idle and absolute fields. List the clients a limit does not cover. Give the console a shorter limit than the product, as Google does. Ask whether a change applies now or at next sign-in, since Okta needs active sessions closed and Atlassian waits for the next login. Warn users before expiry. Entra’s default is a rolling 90 days, and Microsoft warns that frequent prompts teach people to type credentials without thinking.

Which actions should ask for a fresh sign-in?

GitHub’s sudo mode asks for confirmation before sensitive actions such as creating tokens, changing organization security settings and regenerating recovery codes. It lasts two hours, and each sensitive action resets the timer. OWASP adds reauthentication after a login from a new address and during account recovery. Entra cautions that asking too often can cause MFA fatigue.

Our list for the policy page: editing IP rules, turning off enforced MFA, changing recovery contacts and lifting a lock.

How do tokens, service accounts, mobile apps and SSO meet an IP rule?

Vendors disagree, so the screen must say which clients a rule reaches. GitHub’s allow list covers SAML and OIDC sign-in, personal access tokens, SSH keys and the Actions token, but not installation tokens when an app installed on a personal account reaches the organization. Atlassian blocks out-of-range users from its APIs yet exempts some app types, including Connect apps. Google does not enforce session length on OAuth-authenticated apps. NIST notes that identity provider and service sessions are managed independently. Our guide to API keys and service accounts covers the key list; the question here is which rules a key inherits.

What belongs in the audit trail?

GitHub logs enabling and disabling an IP allow list and each entry created, changed or deleted. Entra records each policy’s result at sign-in, report-only included, and recommends alerts on every emergency account sign-in. Our suggestion: store who, when, from which address, the old and new value, the preview the admin saw and whether re-authentication happened. Email all admins on any break-glass use. Who may edit policies is a roles question, covered in our roles and permissions guide.

What should the empty, enforced and failed states say?

Copy, all ours:

• Empty: “No IP restrictions yet. People can sign in to Kestrelane from any address. Add your office range. We check your current address before you save.”
• Enforced: “IP allowlist on. 3 ranges. Changed Nov 4 by R. Okafor. 2 service accounts covered, 1 exempt.”
• Failed, signed-in user: “You can’t sign in from this network. Ask your administrator to allow 203.0.113.40. Reference 7K3Q.”
• Failed, admin: “Locked out as an administrator? Start recovery. It takes about 24 hours, and every admin is emailed.”

Limit: this detail helps support but tells outsiders an allowlist exists, so show it only after a valid password.

Illustrative worked example: Kestrelane and Brightholm Logistics

Everything here is invented. Kestrelane is a fictional startup that sells invoice-approval software. Brightholm Logistics is a fictional customer with 240 people.

The Brightholm admin drafts one allowlist for everyone, with the two office ranges. The 30-day replay shows 164 people signing in from the offices, 52 from home, 19 on warehouse tablets using mobile data and 5 from a partner firm. That is 164 + 52 + 19 + 5 = 240. The preview says 76 people, about 32%, would be refused.

The admin narrows the rule to Finance plus three admins, 41 people. The preview lists 3 of the 41 as refused: they signed in from home last month. The admin adds the company VPN range, and the preview reads 0 of 41. The other 199 people are untouched. The nightly job runs from a cloud host, so she adds its range too.

The admin sets 15 minutes idle and 8 hours absolute. The screen notes that OWASP puts high-value applications at 2-5 minutes idle, so the choice is the admin’s. Changing a payee’s bank details asks for a fresh sign-in. Two owners and one emergency account are named, with a test every 90 days, and the rule starts in seven-day warn-only mode.

Where do these defaults stop working?

IP lists suit offices and VPNs, and suit carrier networks, rotating home addresses and shared cloud exits poorly. Caps exist, such as Atlassian’s 500 addresses or countries per app, and enforcement lags, as GitHub says changes can take a few minutes. Session coverage has holes on mobile and OAuth apps. NIST’s values are federal targets, mostly SHOULD, and OWASP’s numbers are examples. We read vendor documentation and tested no product. We could not open Salesforce’s pages, so it is not covered. No source we read says how often lockouts happen. The 30-day replay, seven-day warn-only mode, 15-minute prompt and 24-hour wait are our rules. Whether a rule meets a customer’s requirement is for that customer’s security team.

What can you produce now?

Six outputs, before a customer asks for these policies:

1. A policy map: four layers, their order and which block wins.
2. A preview spec: 30-day replay, a named list and an own-address check.
3. A recovery spec: contacts, proof, delay and notices.
4. The filled interaction worksheet for your clients, with test dates.
5. A copy deck for the empty, enforced and failed states.
6. An audit event list, with the break-glass alert.

If you want a design partner for these console screens, our comparison of agencies that publish B2B SaaS platform cases shows what each one publishes.