How to get alerted on authentik security events with notification rules
authentik turns selected audit events into notifications through event matcher policies, notification rules and transports, so you hear about risky activity without watching the admin event log. The matcher policy selects events by action, app, model and client IP, and accepts AKQL queries to narrow the match further. A notification rule then sends the matched events to a transport, which is the delivery channel such as email or a webhook. Start by deciding which events must reach a person and which can wait for a periodic review.
The authentik hardening guide names the events to watch first. It recommends notifications for login_failed and suspicious_request, alerts on impersonation events, and alerts on model_created, model_updated, model_deleted and secret_view. The first group points to credential guessing or probing, the impersonation events show someone acting as another user, and the model and secret events show configuration or sensitive-value changes. Build one matcher per group so responders can tell the categories apart, and test each rule by triggering a harmless event in a non-production instance. Confirm the exact action names in your version's event list before you write the matchers.
Notification rules fit teams that want a short list of high-signal alerts in the tool they already read, such as a chat channel or an on-call inbox. Forwarding all events to a SIEM fits teams that need correlation, retention and searchable history, which is a separate decision covered in the SIEM forwarding topic. Most teams need both: notifications for immediate action and a SIEM for investigation. Check AKQL availability against your version, because AKQL became free for everyone in 2026.5, and confirm the transport options your edition supports.
Which authentik events the hardening guide says to watch
The authentik hardening guide names a short list of events worth notifying on. Together they cover attempts against sign-in, misuse of administrator privileges, and changes to the configuration that controls who can get in. Each card below names the event, why a responder should care, and what to check first.
Failed logins and suspicious requests
The login_failed and suspicious_request events are the hardening guide's baseline for notifications. A burst of failed logins can point to password guessing or a misconfigured client that keeps retrying with stale credentials, and suspicious requests can show probing of endpoints the user never reaches. Check the client IP, the username or application involved, and whether the same source appears across several accounts. Confirm the alert destination is monitored before relying on it.
Impersonation events
The guide recommends alerting on impersonation, which lets an administrator act as another user. This is a sensitive capability because actions taken during impersonation are recorded under the target account, so the trail can look normal at a glance. Check who started the impersonation, which user was impersonated, the time window, and whether a ticket or change record justifies it. Treat an unexplained impersonation as a potential insider or account compromise case.
Model creation events
The model_created event records new objects in authentik, such as providers, applications, users, flows, policies and tokens. New objects can expose applications to new users or create credentials that outlive an investigation. Check the object type, the actor who created it, and whether it matches an approved change. Pay particular attention to new administrators, new OAuth or SAML providers, and new application bindings that were not part of a planned rollout.
Model update and deletion events
The model_updated and model_deleted events show changes to existing configuration. An edited flow, policy or provider can weaken authentication or redirect logins, and a deleted policy can silently remove a control. Check which object changed, what fields were modified, and who made the change. Compare the result against your configuration as code or change records so that an unplanned change stands out quickly.
Secret view events
The secret_view event records when someone reads a stored secret, such as a client secret or an API token value. Reading a secret is a common step before an attacker reuses it elsewhere, so the event deserves its own alert. Check who viewed the secret, whether that person needed it for a documented task, and whether the related integration should be rotated. Confirm which roles in your deployment can view secrets at all.
How event matchers, notification rules and transports fit together
An event matcher policy only decides whether an event matches. It selects events by action, app, model and client IP, and it can also accept an AKQL query for finer selection. AKQL became free for everyone in 2026.5, according to the authentik 2026.5 release notes, so on that version or later you can write queries without an enterprise license. If your deployment runs an earlier version, confirm with the vendor or in your own test instance how matching was expressed there before you copy any example into production, because the query options available to you may differ.
A notification rule sits after the matcher and decides what happens when a matched event fires. It is the step that turns a match into an action, such as sending a notification through a chosen transport. Keep the two apart in your design: the matcher answers which events you care about, and the rule answers what you do about them. Changing a matcher does not change where notifications go, and changing a rule does not change which events qualify. Reviewers auditing your alerting should be able to read each part on its own.
A transport delivers the notification to its destination, and the transport you configure determines whether anyone receives the alert at all. Before relying on the chain, send a test event that you know will match, confirm that the notification arrives at the intended channel, and check the event and delivery logs for the rule. Record the transport settings, the rule name and the matcher definition together, so that a failed delivery can be traced to one of the three parts without guessing.
Matcher, rule and transport options and when each fits
This table compares the ways to narrow security event alerts in authentik, from matching on action alone to AKQL queries and the transport you send alerts through. Read each row for when it fits and what it costs in noise or missed coverage. Start narrow for high-risk events like impersonation and configuration changes, and widen only after you have seen the volume.
| Option | When it fits | Trade-off |
|---|---|---|
| Match by action only | Broad coverage of the events the hardening guide names, such as login_failed, suspicious_request, impersonation and model changes | High volume on busy instances; login_failed alone can flood a channel during a password spray or a bad integration |
| Match by app | Separating alerts for the core admin area from events raised by other applications or outposts | Events from apps you did not expect can be missed if the matcher is too narrow |
| Match by model | Watching configuration changes to providers, applications, flows, policies or users, where model_created, model_updated and model_deleted matter most | Blind to changes made through paths that do not write the model you matched; confirm coverage in testing |
| Match by client IP | Flagging activity from addresses you do not expect, such as admin actions from outside your management network | Needs a maintained list of trusted addresses; behind a reverse proxy, confirm the client IP is the real one before relying on it |
| AKQL query | Combining action, model, user and IP conditions in one rule, or filtering out known noise such as a service account | Queries need review as schemas change; test each one against real events before you rely on it |
| Separate rules per severity | Sending impersonation and secret_view to a fast channel while routing routine login failures to a daily summary | More rules to maintain and test, and a risk of gaps if one rule is disabled during maintenance |
| Transport type | Matching the channel your on-call team already watches; confirm the supported transport types in the authentik policies documentation before you design around them | Each transport needs its own delivery test, secret handling and failure monitoring; a silent delivery failure leaves you without alerts |
Configuring the first security event alert in authentik
This sequence takes you from confirming your authentik version and target events to a working notification rule that delivers a test alert, then extends coverage to impersonation and model change events. Each step ends with a check so you can confirm the alert fires only on the events you intended.
Confirm version and the events you need
Before building anything, confirm which authentik version your deployment runs and which event actions you plan to alert on. Check the running version in the admin interface and compare it with the supported release lines listed in the security policy. Then list the actions the hardening guide recommends watching: login_failed, suspicious_request, impersonation events, and model_created, model_updated, model_deleted and secret_view. Confirm with your security team which of these they need paged and which only need to be logged. Done when you have a written list of target actions and a confirmed version that receives security fixes.
Create an event matcher policy for login failures
In the admin interface, create an event matcher policy that matches the login_failed and suspicious_request actions. Use the action field first, since it is the most direct filter. Add a client IP or application condition only if your team has a clear reason, and confirm the policy's exact field names in the policies documentation for your version. Keep the policy narrow so it does not match every event in the system. Done when the policy saves without error and the policy preview or test shows it matching a login_failed event you trigger yourself with a wrong password on a test account.
Bind the policy to a notification rule
Create a notification rule that uses the event matcher policy as its trigger, and set a clear name and severity that your on-call team will recognize. Notification rules decide what happens when a matching event occurs, so bind the policy to the rule and leave other trigger settings at their defaults until you have tested. Confirm in your version's interface where the rule is attached, since the binding screen can differ between releases. Done when the rule shows the matcher policy as its bound condition and the rule is enabled.
Configure a transport and send a test event
Create a notification transport for the channel your team reads, such as an email address, webhook or chat integration your organization already operates. Attach the transport to the notification rule, then trigger a deliberate failed login on a disposable test account. Watch for the notification at the destination, and check the event entry in the admin event log to confirm the action name and timestamp. Done when the test notification arrives at the intended channel and its content identifies the login_failed event, with no duplicate messages from one attempt.
Verify the rule fires only on intended events
Trigger one event of each type you did not intend to alert on, such as a normal successful login, and confirm no notification arrives. Then trigger a suspicious_request if your environment allows it, and confirm it produces a notification. Review the notification history or event log for unexpected matches. If noise appears, tighten the matcher by adding conditions rather than broadening the rule. Done when successful logins produce no alert, the intended security actions do, and you have recorded the test results for your change log.
Add impersonation alerts
Create a second event matcher policy for impersonation events and bind it to its own notification rule, so high-priority admin activity has a dedicated route. Keep this rule separate from login failure alerts so responders can triage it differently. Confirm the exact impersonation action name in the event log by performing a controlled impersonation on a test account, then match that name in the policy. Done when a deliberate impersonation on the test account produces a notification on the dedicated rule and the login failure rule stays silent for that action.
Add configuration change matchers
Add event matcher policies for model_created, model_updated, model_deleted and secret_view, either as one policy with multiple actions or as separate policies, depending on how your team wants to route them. Make a harmless configuration change on a test object, such as editing a description, and confirm the model_updated event produces a notification. Consider whether secret_view alerts will be noisy in your environment before enabling them for every user. Done when each configured action produces the expected notification on test activity, and you have a documented list of which rules cover which actions for your next review.
Tuning alerts for failed logins, impersonation and config changes
Failed logins are the event most likely to flood a channel, because password spraying, expired sessions and misconfigured clients all produce them. The hardening guide recommends notifications for login_failed and suspicious_request, so the goal is not to silence them but to decide which failures deserve a human. Start by scoping the event matcher policy to the applications and client networks that matter, then route the rest to a lower-priority destination or to log storage only.
- Scope by client IP: Match on known corporate or VPN ranges for interactive users, and create a separate rule for unexpected sources. A spike from an unfamiliar range is more informative than a steady trickle from a known office.
- Scope by app: A failed login against a privileged admin application should alert immediately, while failures on a low-risk internal app can be batched.
- Use AKQL to combine conditions: AKQL queries let you express thresholds and combinations that a single matcher cannot, such as the same source failing across several applications.
- Separate suspicious_request from login_failed: Keep them in different notification rules so that a broken client does not drown out reconnaissance signals.
- Review the noisiest sources first: Repeated failures from one client often point to a stale password in a service or a misconfigured integration, not an attack.
After each tuning change, confirm that a deliberate test failure still produces exactly one notification at the expected severity.
Impersonation lets an administrator act as another user, so it is one of the few events where a low volume is the normal state and every occurrence deserves review. The hardening guide recommends alerting on impersonation events. Because real use is rare, the tuning question is usually about who is trusted to impersonate and whether the alert reaches someone who can check the reason, not about reducing volume.
- Alert on every impersonation: Do not suppress by client IP for this event class, since an administrator may be working from an unusual network.
- Match on the actor and target: Include both the acting administrator and the impersonated account in the notification context so reviewers can judge the action quickly.
- Route to an independent recipient: Send these alerts to someone other than the administrator who performed the action, such as a security channel or a SIEM index with restricted write access.
- Document the expected pattern: Write down which roles should impersonate, for what purposes, and how long sessions should last, so reviewers have a baseline.
- Check that alerts survive restarts: Confirm that notification transports are configured and tested after upgrades or configuration changes.
Confirm with a test impersonation in a non-production tenant that the alert arrives with the actor, the target and a timestamp.
Blueprints, CI pipelines and configuration-as-code tools change authentik objects constantly, so model_created, model_updated and model_deleted events can overwhelm a channel during each deployment. The hardening guide recommends alerts on these model events, and the task is to recognize expected automation without losing the ability to spot a manual change made by a person.
- Identify the automation identity: Changes made by a dedicated service account or blueprint process should be distinguishable from changes made through a person's session. Scope your matchers to the human-driven path.
- Scope by model: Alert tightly on high-impact models such as providers, applications, flows, policies and admin roles, and treat low-risk model churn differently.
- Batch expected deployments: Where a pipeline runs at known times, use a maintenance window and review the alerts afterward rather than muting the rule.
- Watch for deletions: Deletions and secret_view events are rarely routine, so keep them at high priority even when updates are batched.
- Compare against source control: A change that does not match the committed configuration is a stronger signal than the change itself.
Confirm that a manual edit made outside the pipeline produces an alert that a reviewer can attribute to a person.
A quiet period is a window with few or no events, and it can mean healthy operation or a broken pipeline. Teams often tune alerts during busy periods and forget that silence can also hide faults, such as a notification transport that has stopped delivering or a rule that no longer matches after a model or field change. Treat the absence of alerts as something to verify, not something to assume.
- Test each rule on a schedule: Trigger a known event, such as a controlled failed login in a test application, and confirm delivery end to end.
- Check transports separately: Verify that the destination accepts messages and that credentials have not expired, since a silent transport looks identical to a quiet system.
- Review rule matches after upgrades: Release notes may change event fields or AKQL behavior, so re-run test events after each version change. Confirm the supported versions in the security policy before scheduling upgrades.
- Keep a heartbeat: Some teams send a periodic test event through the same path as production alerts so that the absence of the heartbeat is itself an alert.
- Record the expected baseline: Note typical daily volumes per rule so that a sudden drop is noticed.
Check that the scheduled test produced a notification in the destination system and that someone on call received it.
Security considerations for alert routing
An alert pipeline is itself a security control, and attackers look for ways to quiet it. The cards below cover the credentials that send alerts, the content those alerts carry, who can change the rules, how hardening alerts survive upgrades, and how each alert gets an owner.
Protect transport credentials and webhook endpoints
Every notification transport holds something useful: a webhook URL with an embedded token, an SMTP login or a chat integration key. Store these as secrets, not as plain text in a shared document, and restrict who can view or replace them. Use HTTPS endpoints that you control, and confirm the receiving system rejects requests it did not expect. Rotate a credential whenever someone with access to it leaves the team, and test the transport after each rotation so a silent failure does not hide the next event.
Limit sensitive data inside alert content
A notification built from an event can carry usernames, client IP addresses, application names and object details. Before a transport goes live, review what a login_failed or model_updated message actually contains, and remove anything that should not leave the identity system. Keep alert bodies short and link responders back to the authentik admin interface for detail. Channels such as chat rooms and shared mailboxes often have wider audiences than the admin team, so choose the destination with that audience in mind.
Control who can edit matchers and rules
An attacker with administrator rights can disable a notification rule, change an event matcher or point a transport at a dead address, and then act without anyone being told. Treat edits to policies, notification rules and transports as high-risk changes. Limit the number of people with permission to change them, and keep a record of who changed what. Confirm that the alerts on model_updated and model_deleted still fire after a matcher change, because those alerts are the ones that would expose tampering with the alert setup itself.
Keep hardening alerts after upgrades
Notification rules and their matchers are configuration stored in authentik, and they are easy to lose during a rebuild, a restore or a migration to a new instance. After each upgrade, compare the active rules with the events the hardening guide recommends: login_failed, suspicious_request, impersonation, and the model and secret_view events. Check the release notes for the version you are moving to, and confirm that AKQL queries still return the expected events. Record the comparison as part of the upgrade change ticket.
Record who acts on each alert
An alert that nobody owns is only a log entry with a delay. Decide which role receives each category, such as failed logins, impersonation and configuration changes, and who is expected to acknowledge and close it. Record the acknowledgement, the investigation and the outcome in your ticketing or incident system. Review unacknowledged alerts on a regular schedule, and confirm that an on-call person still receives the highest-severity events when the primary channel is down.
When notification rules are enough and when a SIEM is needed
Notification rules fit a short list of high-value events that need a named responder within minutes, such as login_failed and suspicious_request events, alerts on impersonation, and changes to models and secrets that the hardening guide asks you to watch. Each rule pairs an event matcher policy with a transport, so the decision you make here is which handful of events justifies an interruption. If a rule fires several times a day with no action taken, narrow its matcher, for example by app, model or client IP, rather than muting the rule altogether. A small team can run a few well-chosen rules without any additional tooling.
Full event forwarding answers different questions. Once you need to correlate a failed login with a later configuration change, search months of history, or hand evidence to an investigator, selective alerts stop being enough because they only show what you chose to catch in advance. Container log forwarding captures every event in the stream, and a SIEM such as Wazuh or OpenSearch adds correlation, retention and case handling on top. Many teams run both: notification rules for immediate response and log forwarding for everything else. The sibling topic on forwarding authentik events to a SIEM covers that pipeline end to end.
Two edition-dependent limits belong in the decision. Local retention of events inside authentik is finite, so confirm how long your deployment keeps them before relying on it as an archive. Enhanced audit logging is listed on the authentik pricing page as an enterprise-only feature, so if your evidence requirements depend on audit depth, confirm with authentik which logging capabilities your edition includes before you design the alert set. Check the authentik hardening guide against your own threat model, and write down which events go to a person, which go to a SIEM, and who owns each path.
Limits to confirm in your environment
Notification rules look simple on paper, but their behavior depends on your authentik version, the transports you enable and how the worker runs. The cards below turn each open question into a check you can run against the docs or a test instance before you rely on alerts for security events.
Transports supported by your version
Confirm which transport types your running authentik version offers for notification rules, and whether the one you need, such as email or a webhook to your SIEM or chat tool, is available without extra configuration. Transport options change between releases, so check the release notes for the version you run rather than an older guide. Send a test notification through each transport and record the payload format the receiving system gets.
Coverage of hardening-guide events
The hardening guide names login_failed, suspicious_request, impersonation events and the model_created, model_updated, model_deleted and secret_view actions. Confirm that a notification rule and matcher fires for each of these in your version by triggering each event deliberately in a test environment. Do not assume that a rule matching one action covers related actions you care about, such as changes to providers or flows.
Event matcher precision
Check how the event matcher handles action, app, model and client IP filters together, and whether your AKQL query syntax behaves as you expect. An overly broad matcher floods the channel with noise, while a narrow one can miss the event you need. Write down the exact match conditions for each alert so an analyst can reproduce why a notification was or was not sent.
Delivery reliability and retries
Ask how authentik handles a transport that is down or slow: whether failed notifications are retried, how many times, and whether a failure is recorded anywhere you can monitor. Confirm this with the docs or by blocking a test webhook endpoint for a short period. Silent delivery failure is the main risk, so decide in advance who reviews failed sends and how often.
Event retention window
Confirm how long authentik keeps events in its database before cleanup, and whether that window is configurable. Notifications leave a copy in your alerting system, but investigators often need the original event later. If local retention is shorter than your incident response or audit needs, forward events to your SIEM as well. Verify the retention setting in your version before you set expectations with the security team.
Worker health and notification dependency
Confirm whether notifications are sent by the background worker container, which means alerts stop if that container is unhealthy or its tasks back up. The architecture stores queued work in PostgreSQL, so check how a stopped worker affects queued notifications and whether they send after recovery. Add a health check on the worker to your monitoring, and test what happens to an alert raised while the worker is down.
Questions teams ask before setting up authentik security alerts
How much effort does setting up authentik security alerts take in-house?
For a single authentik instance with a few notification rules, the work is a bounded configuration task: defining event matcher policies for the events the hardening guide names, creating notification transports, binding rules to those policies, and testing each alert with a deliberate failed login or test change. The larger share of effort usually comes after the first alerts fire, when the team decides which events are worth waking someone up for. Ask your team to estimate the configuration work and the tuning work separately, because they are different skills and run on different timelines. Any duration you are given should come from a written scope with named deliverables.
What makes the alerting effort grow?
Four factors move the effort most:
- The number of event types you alert on. Login failures and suspicious requests are noisy in busy environments, so each added type needs thresholds and a response path.
- The number of transports, such as email, chat or webhooks, each with its own credentials, retry behavior and testing.
- SIEM integration. Routing alerts into Splunk, Wazuh, OpenSearch or another platform adds parsing, field mapping and correlation rules on the receiving side.
- Tuning. Matcher logic filtered by action, app, model and client IP usually needs several rounds against real traffic before false positives drop to a level the on-call team accepts.
Each factor adds one-time work, and tuning and SIEM rules also recur whenever your applications or user population change.
Does the open source edition of authentik include security event alerting?
The core of authentik is released under the MIT license (SPDX: MIT), and the event matcher policies and notification rules used for alerting are part of that open source code base. Code in the authentik/enterprise/ directory is under a separate enterprise license, and the pricing page lists enhanced audit logging as enterprise-only. Confirm the exact feature boundary against the authentik pricing page and the license text in the repository before you design around a specific capability, because a feature that depends on enhanced audit logging may not be available to the open source edition. Your legal team should read the license files directly, since this page does not give legal advice.
What does the team need to provide for alerts to work?
Three roles need named owners before the work starts:
- An authentik administrator who can create policies, rules and transports and who has access to the admin interface and its event log.
- A receiving system, such as a chat channel, mailbox, SIEM or ticketing queue, with someone who maintains its credentials and delivery path.
- On-call ownership, meaning a person or rota who acts on each alert class and agrees what counts as urgent. Without this, alerts for impersonation or configuration changes will be sent somewhere no one reads.
Also confirm that the authentik version you run is one that receives security fixes, as listed in the security policy, so your alerting design does not depend on an unsupported release.
Which events should we alert on first?
Start with the events the authentik hardening guide recommends: notifications for login_failed and suspicious_request, alerts on impersonation events, and alerts on model_created, model_updated, model_deleted and secret_view. These cover credential attacks, probing, privilege misuse and configuration drift. Add them in small groups so each one can be tested and tuned. Confirm the current event names in your own version's documentation, since the hardening guide is the reference for which events to watch.
Should we hire outside help to set up authentik security alerts?
Outside help makes sense when your team lacks time, when the receiving SIEM is unfamiliar, or when you need the alerting design reviewed before it goes into production. DeployOpen plans, implements, documents and supports self-hosted open-source platforms in your own infrastructure, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts. A quote follows from that written scope, and DeployOpen does not publish a price list. Ask any provider for the list of event types covered, the transports and SIEM connections included, the tuning rounds, the handover documentation, and whether ongoing tuning is a separate retainer.
What should a quote for alerting work include?
A useful quote separates one-time and recurring costs:
- One-time: design of the event list, matcher policies, notification rules, transport setup, receiving-side configuration and acceptance testing.
- One-time or recurring: tuning rounds and documentation, depending on how the work is scoped.
- Recurring: review of alert volume, updates when authentik releases change event behavior, and ongoing tuning as the user base grows.
Ask who pays for each item, what the receiving system's licensing costs are, and whether acceptance criteria are written down. Compare quotes on the same written scope rather than on headline effort.
Can alerts replace a SIEM for authentik events?
Notification rules can tell your team quickly when a specific event occurs, but they do not replace long-term retention, correlation across systems or investigation workflows. Most teams use alerts for immediate response and forward the full event stream to a SIEM or log platform for search and retention. Check the local retention settings in your authentik version, since events kept only in the database have a limit set by your configuration. Confirm this design with your compliance and incident response leads before you rely on it.
How DeployOpen scopes and supports authentik alerting
DeployOpen plans, implements, integrates and documents security alerting for authentik inside your own infrastructure, whether that is your cloud accounts, data centers or air-gapped network. In practice that covers the choices in this topic: which events become notifications, how the event matcher policies are written, which notification transports reach your on-call channel or SIEM, and the runbook that tells responders what to do when a login_failed burst or a model_deleted event arrives. Most engagements are fixed-scope, so the list of alert rules, the transports, the test cases and the handover documents are agreed in writing before any work starts. Ask for that written scope to name each event category, each destination and the owner of every rule.
Ongoing tuning is handled as a retainer rather than an open-ended engagement. Alert volume usually needs adjusting after the first weeks of real traffic, authentik releases can change event payloads or policy behavior, and new applications bring new admin actions to watch. A retainer can cover reviewing noisy rules, checking that notification rules still fire after upgrades, and extending coverage as your estate grows. Confirm with DeployOpen what is included in any retainer, how change requests are logged, and how quickly the team responds to a request, since these terms belong in the written agreement and are not fixed here.
DeployOpen runs security testing to check that alerts fire when they should. That means triggering failed logins, simulated suspicious requests and admin changes in a test environment and confirming that the right people are notified with usable detail. This testing validates the alerting work, but it is not an audit. DeployOpen does not issue audit reports, attestations or certifications, and if your alerting supports a compliance assessment, the independent auditor or certification body decides whether the controls meet the requirement. Ask for the test evidence as a deliverable so your assessors and your own team can review it.
