Authdog
Security guide

Threat Mitigation

Authdog provides practical identity-risk controls through environment restrictions, authentication policy, session revocation, audit investigation, and optional Lidar access. Repository marketing describes broader automated response capabilities, but current console code does not verify production controls for automatic step-up, IP blocking, agent quarantine, account freezing, or configurable rate limits. Use the controls below as a defensible prevention-and-response baseline, and validate every action in the target environment.

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 method to verify users during account recovery.
  • Known allowed and denied email domains if restrictions will be used.
  • An inventory of sensitive application routes and their server-enforced permissions.

Capture the tenant, project, and environment identifiers in your runbook. Authdog environments isolate signing keys, connections, users, and policies, so an action in the wrong environment may be ineffective or disrupt unrelated testing.

Implementation

  1. Reduce authentication exposure. Enable only sign-in methods your application needs. Use a breach-aware password policy where password authentication remains enabled. Add TOTP MFA for applicable users, while recognizing that TOTP codes can be phished. For hosted passwordless authentication, evaluate passkeys and retain an independent recovery route.

  2. Restrict account creation and access. Open Lidar → Restrictions. For controlled B2B applications, consider Restricted sign-up, which limits entry to invitations, manual creation, or enterprise SSO. Configure email-domain allowlists or blocklists where domain ownership is a valid access signal. You can apply these lists to sign-in as well as sign-up. Optional sign-up controls reject disposable-email domains or limit distinct subaddresses associated with one base address.

  3. Do not rely on prototype policies. The console labels country policies as an interactive UI prototype whose persistence and enforcement will follow. It also states that rate-limit presets and per-route overrides are planned for a future release. Do not treat either screen as an active mitigation, even if controls can be clicked. Keep existing edge, gateway, or application rate limits in place until enforcement is proven with traffic tests.

  4. Request and verify Lidar access. The Lidar overview exposes an access state: no access, pending, or approved. Request access for the intended environment and wait for Protection active before treating Lidar as enabled. The UI names detection categories including bot activity, brute force, domain protections, impossible travel, repeat sign-up, stale accounts, unrecognized devices, and enforced restrictions. Confirm real detections appear for your environment; zero-value cards alone do not prove telemetry or blocking.

  5. Build an investigation view. Open Audit, select the environment, and narrow the time range. Filter by category, event type, user, browser, operating system, location, external ID, or event details. Start from a known UTC timestamp and user, then inspect adjacent authentication, MFA, user-management, and configuration events. Preserve relevant raw event payloads in your controlled incident system before remediation.

  6. Contain compromised sessions. Open the affected user and review active sessions, including device context, expiration, and revoked state. Revoke suspicious sessions individually. The management service records a revokedAt timestamp for the selected session in the selected environment. Confirm the session can no longer access a protected backend route.

  7. Correct identity configuration. Depending on evidence, remove an organization membership, correct role assignment, reset MFA through the console after independent identity verification, rotate an upstream provider credential, or disable a misconfigured connection. Use the smallest action that contains the incident without widening impact.

  8. Confirm the response. Repeat the denied request, inspect the affected user and session state, and review new audit activity. Record what was observed, what changed, who approved it, and what validation passed. For a broader investigation procedure, follow Audit logs.

Security considerations

Session revocation is precise; account-level or organization-level action has wider impact. Verify user, environment, session ID, and active organization before changing state. Never use audit payloads directly for authorization, because fields vary by source and can be nullable.

An email domain is not proof that a person is currently authorized by an organization. Combine restrictions with invitations, enterprise SSO, organization membership, and backend permission checks. See B2B authentication for that model.

Keep incident exports encrypted and access-controlled. Event details can contain personal data, IP addresses, user-agent data, and source-specific fields. Redact before copying evidence into chat or ticket systems.

Do not automate response from an event name you guessed. Discover and inspect observed event types first. If routing events to another system, apply the verification process in SIEM security events.

Validation checklist

  • Production and test environments use separate users, keys, and policies.
  • Unneeded sign-in methods are disabled.
  • Allowed and denied sign-up cases behave as configured.
  • Domain restrictions behave correctly for sign-in when that option is enabled.
  • Disposable and subaddress tests match intended sign-up policy.
  • Lidar shows approved access before it is counted as active.
  • A known suspicious test produces an expected, inspectable signal where supported.
  • Audit filters locate the test event using UTC time, user, and event type.
  • Revoking a test session changes its state and causes backend access to fail.
  • Legitimate sessions and users outside the tested scope remain unaffected.

Troubleshooting

If restrictions appear ineffective, confirm the selected environment, save state, and whether lists apply only to sign-up or also to sign-in. An enabled allowlist cannot be saved empty. Test exact addresses rather than assuming parent-domain or alias behavior.

If Lidar remains pending, treat protection as unavailable and retain other controls. If it is approved but dashboards remain empty, generate a safe test in a non-production environment and correlate it with Audit before escalating.

If a revoked session still succeeds, verify the request is using the same session and environment you revoked, then test the backend's validation path. A UI-only client check can continue showing stale state and is not sufficient evidence.

Next steps