Windows Event ID 4698 is the security event logged when a scheduled task is created on a Windows system. It records task registration details such as the task name, author and action, and is used to detect persistence, unauthorised automation and changes that may run code later under a system or service account.
What the event means in practice
Windows Event ID 4698 is the point at which a scheduled task becomes an artefact defenders can inspect, not just a configuration choice. The event usually matters because the task definition can outlive the actor that created it, and the scheduled action may later run with elevated, system, or service context.
That makes the event useful for understanding intent. A task name, author, trigger and action can show whether the registration was expected administration, automation, or a new persistence mechanism introduced after compromise.
Why scheduled task creation is security-relevant
Scheduled tasks are attractive to attackers because they provide repeat execution without needing an interactive session. A task can launch a payload after reboot, on a timer, or in response to a trigger, which turns a single registration event into durable foothold if the task is not reviewed.
The risk is amplified when the task runs under a privileged account or uses embedded command lines, scripts, or binaries from writable locations. That is why task creation is often assessed alongside service creation, logon activity, and other persistence-related events in Windows telemetry.
For a broader view of how this event fits into Windows auditing and related event IDs, the Windows Event Log Guide is the most direct starting point.
What defenders look for in the event record
Event 4698 is most valuable when you read it with surrounding telemetry. The task name, creator, action path, arguments, start time, run-as account and host context help determine whether the task is benign automation or a suspicious persistence primitive.
Defenders also compare the creation event with subsequent execution and modification events. If a task appears suddenly, is renamed to look administrative, or points to unusual binaries, that pattern deserves closer review in endpoint telemetry and Windows event forwarding pipelines.
The T1053 Scheduled Task/Job Defensive Guide explains the abuse patterns that make scheduled tasks so operationally important, while the Sysmon Guide helps place task creation in a wider host-telemetry strategy.
How to investigate and respond to suspicious task creation
When Event 4698 is unexpected, the first question is whether the task aligns with approved change or software deployment. If not, the investigator should treat it as a potential persistence or automation event and inspect the task XML, the launch command, the account context and any related parent process activity.
Response usually focuses on removing the task, checking whether the underlying binary or script still exists, and looking for the same creator or host pattern elsewhere. If the task was used after compromise, the follow-up question is whether the same actor also touched services, run keys, logon scripts, or other persistence mechanisms.
Risk and Threat Considerations
Scheduled task creation is a common persistence path because it is built into Windows administration and can look routine at first glance. The main risk is that a legitimate-looking task can provide repeated execution, privilege retention, or delayed re-entry long after the initial intrusion.
Failure mechanism: An attacker creates or modifies a task that launches a payload on a timer, at logon, or after reboot, then hides the task among normal administrative automation.
Impact: The system may continue executing attacker-controlled code, sometimes under elevated context, which can support persistence, lateral movement, or post-compromise automation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1053 — Scheduled Task/Job | Event 4698 logs scheduled task creation, which maps directly to this persistence technique. |
| Recommendation — Correlate new scheduled tasks with T1053 analytics and alert on unexpected creation, modification, or hidden execution paths. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Event 4698 is only useful when task creation is retained, centralised, and reviewed in logs. |
| Recommendation — Centralise Windows audit logs so scheduled task creation events can be reviewed and retained for investigations. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | 4698 is an audit record that requires review and correlation to identify suspicious task registration. |
| AU-12 — Audit Generation | The event depends on Windows audit generation being enabled for task registration activity. | |
| CM-7 — Least Functionality | Unexpected scheduled tasks often expand the system's executable surface and allowed automation paths. | |
| Recommendation — Review scheduled task creation events and correlate them with related host activity to spot persistence. Enable auditing that generates task creation events so registration activity is available for detection. Restrict authorised scheduled tasks to approved use cases and remove unnecessary execution paths. | ||
Practitioner Guidance
What to watch for: Treat Event 4698 as a change event, not just a log entry. In practice, the highest-value triage question is whether the task creation was expected, attributable, and consistent with normal automation ownership.
Practitioner takeaway: The safest operational posture is to pair task creation review with strong allowlisting of sanctioned automation, so a new scheduled task stands out immediately when it is not part of an approved change.
Related resources from NHI Mgmt Group
- Windows Security Event 4698
- Why do macOS logs need different handling than Windows event logs?
- What do organisations get wrong when they assume Windows event logs are enough to spot Group Policy abuse?
- How should security teams implement phishing-resistant Windows sign-in for Entra ID users without creating device lockout risk?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 3, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org