Turn on Conditional Access
To turn on conditional access, open your identity tool and build a new login rule. Next, pick your users, add device or location checks, and set the rule to active. Most teams start by watching login logs before they block any real users. This careful test phase stops accidental lockouts across the company. Still, login rules alone leave a big gap when user roles stay too broad. How to turn on conditional access in your identity tool Conditional access works as an automated check during every
Conditional Access Policies + Single Sign-On (SSO): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
To turn on conditional access, open your identity tool and build a new login rule. Next, pick your users, add device or location checks, and set the rule to active. Most teams start by watching login logs before they block any real users. This careful test phase stops accidental lockouts across the company. Still, login rules alone leave a big gap when user roles stay too broad.
How to turn on conditional access in your identity tool
Conditional access works as an automated check during every user login attempt. It reads signals like user role, network location, device health, and target app. When all signals match your rule, the system grants or blocks the login. It can also ask the user for a second login factor right away.
To set up your first rule, define who the rule covers. Start with a small test group of engineers instead of the whole company. Always exclude at least one break-glass admin account from every rule you build. That way, your team still has a way in if a rule fails.
Next, pick the cloud apps or internal tools that the rule will guard. Then add the conditions that trigger a deeper check, such as untrusted networks. Set the control action to require a fresh multi-factor check or a managed device. Turn the rule to a report-only state first so you can check the logs. Once the logs look clean for a week, switch the rule to active.
What login rules solve and what they miss
Turning on conditional access stops bad logins at the front door. Stolen passwords fail when an attacker tries to log in from an unknown device. It also forces extra checks when someone logs in from a new country. For web apps, this front-door check blocks most external threats.
Still, conditional access only decides who can log in to an app or network. Once the login check passes, the identity tool steps out of the way. It cannot see what a user does inside a database or server session. If an engineer has a broad admin role, they can run any command.
Conditional Access Policies + Single Sign-On (SSO): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
A single bad query can drop a table or pull thousands of customer emails. Login rules also struggle to govern command-line tools, scripts, and AI agents. Teams need controls that inspect live commands and mask fields like card numbers in results.
Best practices for rolling out login rules
Keep your rules simple and give each rule a clear, plain name. Group users by job role so you do not have to edit rules often. Check your sign-in logs every day during the first two weeks of a rollout. If users get blocked by mistake, adjust the location or device check right away. Combine front-door login rules with action-level checks for complete safety across your stack.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
What happens if a conditional access rule locks out all admins?
If a rule blocks every admin, you cannot edit the rule to fix it. Always keep one emergency admin account excluded from all login rules. Protect that emergency account with a long password stored in a safe place.
Should I turn on conditional access for all users at once?
No, turning on a new rule for everyone at once often breaks daily work. Run the rule in a log-only mode first to spot false blocks. Next, apply the active rule to a small test group before a full rollout.
Does conditional access control database queries after login?
No, conditional access only checks the user and device during the initial login step. It does not read or filter SQL queries, shell commands, or API calls in flight. You need command-level controls and data masking to protect data during an active session.