The Windows Startup Folder is a user or all-users folder where shortcuts are placed so selected programmes run automatically when a person signs in. Windows reads the folder during logon, so anything launched there inherits that user context and can affect persistence, startup behaviour and access to network or local resources.
What the Windows Startup Folder actually does
The Windows Startup Folder is a logon autostart location, so shortcuts placed there are launched when a user signs in. That makes it simple for legitimate helpers, but it also means anything introduced there inherits the user session context and can shape what runs at every logon.
Because Windows processes this folder during sign-in, it is best understood as an execution trigger rather than a storage location. The folder is one of several ways software can achieve boot or logon autostart behaviour, alongside other persistence paths that defenders often inspect together, including the broader patterns covered in the Persistence Techniques Guide.
Why the Startup Folder matters for persistence
For attackers, the Startup Folder is attractive because it is familiar, low friction and often overlooked during basic triage. A shortcut, script or wrapper placed here can deliver repeatable execution without needing a service, driver or scheduled task, which is enough for many post-compromise persistence goals.
The danger is not the folder itself, but the fact that a simple logon trigger can repeatedly relaunch code with the same account context. If that account has access to file shares, browser sessions, local secrets or internal tools, the autostarted process may inherit that reach and reuse it silently.
Defenders should treat this as part of the larger boot or logon autostart family, and T1547 Boot or Logon Autostart Execution Defensive Guide is the natural companion for detection and eviction thinking across startup folders, run keys and related autostart paths.
How attackers and administrators use it differently
Administrators may use the Startup Folder for benign user experience tasks, such as launching collaboration tools, sync agents or profile helpers. In those cases, the shortcut is usually transparent and expected, and the main concern is operational discipline rather than stealth.
Malicious use looks similar on the surface, which is why the context matters. A suspicious shortcut target, an unexpected script host, an odd working directory, or a renamed binary in a user-writable path can all signal abuse of the same mechanism. The folder is especially useful to adversaries because execution can look like ordinary user startup activity unless the target and provenance are checked.
What defenders should verify and monitor
The practical security question is whether the Startup Folder contains only approved entries and whether those entries are consistent with the owning user or system image. Teams should know where both the per-user and all-users variants live, and they should compare the contents against baseline software, expected shortcuts and recent change history.
It also helps to look at the autostart entry in the wider identity and access context. If a logon-launched shortcut points to a process that can reach administrative shares, saved browser sessions, cloud tokens or other sensitive resources, the impact of a seemingly minor persistence change increases sharply.
For broader detection strategy, Windows Startup Folder inspection pairs well with endpoint startup visibility, autoruns baselining and logon-time process review. The point is not just to find an entry, but to decide whether it belongs there and whether it should be able to execute at all.
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 NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1547.001 — Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder | This term is a logon persistence mechanism covered by T1547.001. |
| Recommendation — Map startup-folder entries to T1547.001 and hunt for unexpected logon autostart execution. | ||
| NIST SP 800-53 Rev 5 | CM-8 — System Component Inventory | Startup-folder entries should be checked against an approved software and autostart inventory. |
| SI-4 — System Monitoring | Detection of persistence in a Startup Folder depends on monitoring logon-time execution changes. | |
| Recommendation — Inventory approved logon autostarts and remove unapproved Startup Folder entries. Monitor logon-time process launches and alert on new or altered Startup Folder shortcuts. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Startup folders are configuration points that should be hardened and baseline-checked. |
| CIS-8 — Audit Log Management | Audit logs help confirm who changed startup entries and when execution occurred. | |
| Recommendation — Baseline startup locations and block unauthorized autostart configuration drift. Collect and review logs for creation or modification of Startup Folder entries. | ||
Related resources from NHI Mgmt Group
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 October 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org