Set security policies

Set the rules that protect access — password and multi-factor requirements, lockout, session bounds, and network restrictions — the foundation of a defensible deployment.

Security policies are the rules every user is held to: password requirements, multi-factor settings, session controls, and network restrictions. Setting them well is foundational to a defensible, regulated deployment, so this guide walks the four areas in turn. For the reference, see Security Policies.

Govern passwords

Start with credentials — or, where you can, remove them as an attack surface entirely.

Before you start In the Identity Portal, go to Security Policies. You'll need administrator access.

  1. Set password length and complexity rules, block passwords containing user information, and require periodic change where your policy calls for it.
  2. Where you authenticate entirely through single sign-on, disable password login entirely — removing local passwords as an attack surface altogether.

Result Password-based access is governed to your standard, or eliminated in favor of SSO. See Security Policies.

Require MFA and stop brute force

Layer a second factor on top, and make repeated guessing fail fast.

  1. Require multi-factor authentication, and review its status across the organization.
  2. Set how many failed attempts are allowed before lockout, so brute-force attempts are stopped rather than left to keep trying.
  3. Enable automatic blocking of suspicious login attempts.

Result Sign-in is protected by a second factor and defended against guessing and suspicious activity.

Bound sessions and networks

Finally, make sure a stale session or an unexpected network can’t be exploited.

  1. Set an idle timeout for inactivity and an absolute timeout that caps a session regardless of activity, limit maximum concurrent sessions, and encrypt session storage.
  2. Confine access to allowed IP ranges, so the platform can only be reached from networks your organization expects.

Result Unattended or stale sessions can't be exploited, no account is used from many places at once, and access is confined to known networks.

Note These policies are strongest as part of a whole posture, not in isolation. The authentication logs record their effect, and SSO is the front door they protect — if you authenticate solely through SSO, disabling password login closes the local-credential door for good.

Where to go next

To see these policies taking effect in the sign-in record, see Authentication Logs. For the single sign-on that these rules sit behind, see SSO Configuration.

Was this helpful?