Authdog

Security guide

Threat Mitigation

Authdog provides practical identity-risk controls through environment restrictions, authentication policy, session revocation, and audit investigation. This guide builds a defensible prevention-and-response baseline; broader automated response (step-up, IP blocking, rate limits) is not yet in production.

Prerequisites

  • A dedicated non-production Authdog environment with representative users.
  • Console permission to manage Lidar settings, authentication, users, sessions, and audit activity.
  • A documented incident owner and an out-of-band way to verify users during recovery.
  • Known allowed and denied email domains if restrictions will be used.
  • An inventory of sensitive routes and their server-enforced permissions.

Implementation

  1. Reduce authentication exposure. Enable only the sign-in methods you need, add TOTP MFA where applicable, and evaluate passkeys while keeping an independent recovery route.

  2. Restrict account creation and access. In Lidar → Restrictions, consider Restricted sign-up for B2B apps and configure email-domain allowlists/blocklists, applicable to sign-in as well as sign-up.

  3. Do not rely on prototype policies. Country policies and rate-limit presets are currently labeled as UI prototypes without confirmed enforcement. Keep existing edge or application rate limits in place until enforcement is proven.

  4. Request and verify Lidar access. Wait for Protection active before treating Lidar as enabled, and confirm real detections appear, zero-value cards alone don't prove telemetry.

  5. Build an investigation view. In Audit, narrow by environment, UTC time, category, user, and other filters. Preserve relevant raw event payloads before remediation.

  6. Contain compromised sessions. Review a user's active sessions and revoke suspicious ones individually, then confirm the session can no longer reach a protected route.

  7. Correct identity configuration. Remove a membership, correct a role, reset MFA after independent verification, or disable a misconfigured connection, using the smallest action that contains the incident.

  8. Confirm the response. Repeat the denied request and review new audit activity. Record what changed, who approved it, and what validation passed. See Audit logs for the full procedure.

Security considerations

  • Session revocation is precise; account or organization-level action has wider impact, verify scope before acting.
  • An email domain is not proof of current authorization, combine restrictions with invitations, SSO, and backend checks. See B2B authentication.
  • Keep incident exports encrypted and access-controlled; redact before copying evidence into tickets or chat.
  • Don't automate response from a guessed event name, inspect observed types 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

If restrictions appear ineffective, confirm the environment and whether lists apply to sign-up or also sign-in. If Lidar remains pending, treat protection as unavailable and retain other controls. If a revoked session still succeeds, verify you revoked the same session and environment, and test the backend's validation path directly.

Next steps