authentik Account Lockdown for compromised accounts

authentik ships a packaged blueprint for the Account Lockdown flow, so you do not need to author the lockdown logic from scratch. In authentik, a blueprint is a declarative YAML file that describes objects such as flows, stages and policies, and the server applies it so the same configuration can be reproduced across instances. The practical decision is how you instantiate the packaged blueprint in your deployment: whether you load it through your normal configuration-as-code path, and who on your team owns the change. Treat the blueprint as part of your identity configuration, under the same change control as your other authentik objects, so that the lockdown path is recorded and reviewable before an incident forces its use.

Before applying anything, review the blueprint line by line against the Account Lockdown behavior described in the 2026.5 release notes, and check which objects it creates, modifies or binds to. Confirm that the blueprint version matches the authentik release you are running, because blueprint content tracks the server version and a mismatch can produce objects that do not behave as documented. Also confirm which of your existing flows, stages or policies the blueprint references, since a name collision or an overwritten binding can change sign-in behavior for every user, not only the account you intend to lock down. Ask your vendor or the release documentation to confirm any object you cannot explain.

Confirm the flow in a non-production instance before relying on it in an incident. Load the same blueprint version into a test deployment, lock down a test user from the administrator view and from the self-service path in Settings, and verify that the account is deactivated, the password is invalidated, sessions end and tokens are revoked. Check that the reason is written to the audit log. Record the results in your runbook along with the exact release and blueprint version tested, so responders know the procedure has been validated against the environment they will actually operate.

Account Lockdown is one step in a sequence your incident response process already owns, and it should run only after someone has decided that an account is compromised. Detection, scoping and the approval to act sit with your security team and the people who authorize access changes. Before anyone clicks lockdown, record which account is affected, who approved the action, and the time it was taken, so the audit entry in authentik has a matching record in your incident ticket. Scoping matters because a lockdown stops the identity, not the damage already done: list the applications that trust that user, the API tokens and OAuth grants they may hold, and any shared or service accounts they administer.

Once the account is locked down, capture evidence before anything else changes. The reason you enter is written to the authentik audit log, so use a consistent reason format that your SIEM or case tool can search. Export the relevant audit events and session records first, then check connected applications for activity that continued after the lockdown time, since sessions and tokens in those applications may have been issued before revocation took effect. Confirm with each application owner whether it caches sessions or keeps its own tokens outside authentik, because that determines whether downstream checks are a verification step or a cleanup task. Do not assume that the user's local password change alone closed every path.

Credential reset and reactivation are separate decisions with their own approvals. Reset the password and any second factors through your standard recovery process, and reactivate only after the investigation confirms the account is clean and the user has been verified out of band. Afterwards, hold a post-incident review that asks whether scoping was complete, whether the runbook named the right owners, and whether any application needed a manual check that should be automated. Confirm with your own runbook owners which steps need sign-off, since the organization owns those decisions and the approval path, and check the exact behavior of each step against the authentik 2026.5 release notes in a test environment before you rely on it in an incident.

DeployOpen starts by agreeing the lockdown scope in writing before any work begins. The scope names which authentik deployment is covered, which applications and directories depend on it, who is allowed to trigger Account Lockdown, and which teams must be able to run it during an incident. Because most engagements are fixed-scope, the deliverables and timelines are set out in that document, so the decisions about administrator roles, self-service use and evidence expectations are made before anything is configured. If your incident response team is outside IT, such as a security operations center or an external retainer provider, include them in this scoping conversation.

DeployOpen then installs and configures authentik inside your own infrastructure, whether that is your cloud accounts, data centers or an air-gapped network, and applies the packaged Account Lockdown blueprint. The work includes checking that the admin trigger on the user's detail page and the self-service option in Settings behave as your runbook expects, and confirming that the audit log entry records the reason for each lockdown. Testing then runs with your own administrators and security responders against test accounts, covering the effects on active sessions, API tokens, OAuth grants and app access. Ask the team to confirm the exact blueprint version and any Enterprise licensing it needs before testing begins, since the feature sits in the Enterprise edition.

The runbook steps and evidence collection are written from the tested results, so each step names who triggers the lockdown, what the operator checks afterward and where the audit record is kept. DeployOpen prepares these controls and the evidence that supports them, but it does not issue audit reports or attestations, and independent auditors make that judgment. After handover, ongoing support, upgrades and periodic re-testing can be covered by a retainer, which is useful when authentik versions change and the lockdown steps need to be checked again. Ask for the written scope, the list of tested scenarios and the handover documents as part of any quote.