Authdog
Log In

Security guide

Threat Mitigation

When something looks wrong, you need a short list of controls that actually stop a request, and a way to prove they did.

This guide builds that baseline from sign-in methods, Lidar restrictions, session revocation, and the audit trail. Broader automated response — step-up, IP blocking, rate limits inside Authdog — is not in production yet. Do not plan an incident around it.

Prerequisites

  • A non-production Authdog environment with users who look like the real ones.
  • Console permission to manage Lidar, authentication, users, sessions, and audit activity.
  • A named incident owner, and a way to verify a person that does not depend on the account you are about to lock.
  • The email domains you intend to allow or deny, if you will use restrictions.
  • The sensitive routes in your app, and the server-side permission each one checks.

Practice the revoke-and-confirm loop here before you need it on a live user.

Implementation

  1. Turn off sign-in methods you do not use. Every extra method is another way in. Enable only what the product supports, add TOTP MFA where it applies, and try passkeys if you want them. Keep one recovery path that does not depend on the factor you are changing. Lock yourself out of the test environment once, on purpose, and confirm the recovery path still works.

  2. Decide who is allowed to create an account. Open Lidar → Restrictions. For a B2B app, Restricted sign-up is usually what you want: invitations, manual creation, or SSO, not a public form. Add email-domain allowlists or blocklists when you know the domains. Those lists apply to sign-in as well as sign-up, so test both. Try an address that should pass and one that should fail before you call the list done.

  3. Ignore controls that are still prototypes. Country policies and rate-limit presets are labeled as UI prototypes, and enforcement is not confirmed. Leave them off your runbook. Keep the rate limits you already have at the edge or in the application until you have watched an Authdog control reject a real request.

  4. Treat Lidar as off until it says otherwise. Request access, then wait for Protection active. Open the dashboard and look for a real detection from something you just did. A card full of zeros does not mean telemetry is flowing. Until you see an event, keep the other controls in this guide and do not tell anyone Lidar is on.

  5. Find the event before you change anything. Open Audit and narrow by environment, a UTC time window, category, and user. Save the raw payload of the events you care about before you revoke or suspend. Remediation changes what happens next. It should not be the moment the evidence disappears. The full procedure is in Audit logs.

  6. Revoke the session, then prove the route is closed. Open the user, review active sessions, and revoke the suspicious one. Immediately call a protected route with that session. It must fail. If it still succeeds, you revoked a different session, a different environment, or a path your backend does not actually validate.

  7. Change the smallest thing that contains the incident. Remove one membership, correct one role, reset MFA after you have verified the person another way, or disable the connection that was misconfigured. Account-wide or organization-wide action hits everyone else on that object. Do that only when the session revoke was not enough, and say so in the ticket.

  8. Repeat the denied request and write down what you did. Run the same request that should now fail. Check Audit for the new activity. Record what changed, who approved it, and which check passed. That note is what the next person will trust.

Security considerations

  • Session revocation is precise. Suspending the account or changing the organization is wide. Confirm the scope before you click.
  • An email domain is not authorization. Pair domain lists with invitations, SSO, and a backend check. See B2B authentication.
  • Keep incident exports encrypted and access-controlled. Redact them before they go into a ticket or a chat.
  • Do not automate a response from an event name you guessed. Inspect a real event first. See SIEM security events.

Validation checklist

  • Production and test environments use separate users, keys, and policies.
  • Allowed and denied sign-up cases behave as configured.
  • Lidar shows approved access before it's counted as active.
  • Audit filters locate the test event using UTC time, user, and event type.
  • Revoking a test session changes its state and fails a backend request.
  • Legitimate sessions and users outside the tested scope remain unaffected.

Troubleshooting

Restrictions seem to do nothing. Confirm you are in the environment you edited, then check whether the list applies to sign-up only or also to sign-in. Retry with an address you know is on the list and one you know is not.

Lidar stays pending. Protection is unavailable. Keep the other controls. Do not mark the environment as covered.

A revoked session still works. You may have revoked a different session, or the backend is not validating this environment's session. Hit the validation path directly, with the session id you just revoked, and read the error.

Next steps