A systemd drop-in is a small configuration file that overrides or extends settings for an existing unit. It sits in a drop-in directory and lets administrators change service behaviour, dependencies or environment variables without replacing the main unit file, which affects how the service starts, stops and is controlled.
What a systemd drop-in does
A systemd drop-in is a targeted override layer, not a replacement unit. It lets administrators adjust a few directives, such as environment variables, dependencies, restart behaviour or resource controls, while keeping the base unit file intact.
That design matters because systemd applies configuration through a merge model: the drop-in can change how the service starts, stops and reacts to its environment without forcing a fork of the original unit. The practical result is cleaner local customisation and easier package upgrades.
Where drop-ins fit in service management
Drop-ins are most useful when an organisation needs a local deviation from a vendor-supplied or distribution-managed unit. Instead of editing the main file directly, the administrator records the change in the unit’s drop-in directory, which preserves the upstream unit and makes the local intent easier to inspect.
That separation also helps when multiple layers contribute settings. A base unit may define the service, while a drop-in supplies site-specific values for command-line flags, environment files, timeout tuning or ordering relationships. The end state is the same service identity with a different effective configuration.
For operators, the key idea is that a drop-in changes the evaluated unit definition at load time. If the drop-in is removed, the service reverts to the inherited defaults from the original unit and any earlier directives disappear with it.
How systemd evaluates overrides
systemd does not treat a drop-in as a separate service. It merges the fragment into the unit’s final configuration, so the order and specificity of directives matter. Some settings replace earlier values, while others append or accumulate, depending on the directive type.
That means the safest mental model is “effective configuration,” not “file content.” A unit may look simple on disk, but the live service definition can include inherited settings from the vendor file, administrator changes from one or more drop-ins, and values pulled in through environment files or templated units.
Because of that merge behaviour, change review should focus on the final resolved unit rather than only the base file. Small drop-ins can have large behavioural impact if they alter restart policy, executable arguments, privilege boundaries or the dependencies that control when the service is launched.
Operational and security implications
Drop-ins are convenient, but they also create a subtle control point. A local override can weaken a hardened unit just as easily as it can improve it, especially when it changes execution environment, adds dependencies, widens network access or injects sensitive values into the process environment.
They are also a common place for persistence on Linux systems because service configuration is highly trusted and often reviewed less often than binaries. If an attacker can modify a drop-in, they may be able to influence service behaviour without touching the main package-managed unit.
That is why systemd Service Hardening Guide is useful here: it connects drop-in usage to sandboxing controls, exposure measurement and credential handling in the same service-management model.
Risk and Threat Considerations
Drop-ins can create configuration drift, privilege expansion and persistence opportunities when they are loosely governed. The main risk is not the feature itself, but the fact that a small override can silently change the security posture of a service that operators assume is still running with its original protections.
Failure mechanism: an attacker or careless administrator modifies a drop-in to alter execution flags, environment values, dependencies or hardening directives, then the service is restarted or reloaded with weaker controls.
Impact: the service may gain broader access, expose sensitive configuration, lose sandboxing protections or continue running under a compromised trust model that is difficult to spot during routine review.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | CM-3 — Configuration Change Control | Drop-ins are configuration changes that alter unit behaviour and require control. |
| CM-6 — Configuration Settings | Drop-ins directly define the effective security settings of a systemd service. | |
| SI-7 — Software, Firmware, and Information Integrity | Unauthorized drop-ins can alter trusted service execution and persistence behaviour. | |
| Recommendation — Review and approve unit drop-ins as controlled configuration changes before deployment. Baseline and monitor unit drop-ins to keep effective service settings aligned with policy. Verify unit-file integrity and alert on unauthorized drop-in modifications. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | systemd drop-ins are a secure-configuration mechanism for host services. |
| CIS-6 — Access Control Management | Controlling who can edit unit drop-ins limits privileged service tampering. | |
| CIS-8 — Audit Log Management | Changes to service configuration need auditable evidence for review and detection. | |
| Recommendation — Standardize and audit systemd drop-ins as part of secure host configuration. Restrict write access to unit drop-in paths to approved administrators only. Log and review changes to systemd unit fragments and drop-ins for unauthorized edits. | ||
Practitioner Guidance
Governance implication: treat drop-ins as controlled configuration, not ad hoc edits. A review process should make the effective unit state visible, because the security meaning of a service lives in the merged configuration, not just the vendor file.
What to watch for: unexpected drop-ins, changes to environment values, added dependencies, removed hardening directives and overrides under local administrator paths. Those are the changes most likely to alter service behaviour in a way that deserves explicit review.
Practitioner takeaway: when a service behaves unexpectedly, inspect the drop-in layer as part of the unit, because that is often where the effective change actually lives.
Related resources from NHI Mgmt Group
- What is the difference between Kubernetes probes and systemd readiness signals?
- What should teams check before switching from systemd to sysvinit in embedded systems?
- Why does DROP create extra risk for data brokers with enrichment models?
- Who is accountable when identity verification causes customer drop-off?