diff --git a/man/systemd-analyze.xml b/man/systemd-analyze.xml
index 15e95b0c8f..7becf0133e 100644
--- a/man/systemd-analyze.xml
+++ b/man/systemd-analyze.xml
@@ -112,6 +112,12 @@
timespan
SPAN
+
+ systemd-analyze
+ OPTIONS
+ security
+ UNIT
+
@@ -263,6 +269,29 @@ NAutoVTs=8
The time span should adhere to the same syntax documented in systemd.time7.
Values without associated magnitudes are parsed as seconds.
+ systemd-analyze security analyzes the security and sandboxing settings of one or more
+ specified service units. If at least one unit name is specified the security settings of the specified service
+ units are inspected and a detailed analysis is shown. If no unit name is specified, all currently loaded,
+ long-running service units are inspected and a terse table with results shown. The command checks for various
+ security-related service settings, assigning each a numeric "exposure level" value, depending on how important a
+ setting is. It then calculates an overall exposure level for the whole unit, which is an estimation in the range
+ 0.0…10.0 indicating how exposed a service is security-wise. High exposure levels indicate very little applied
+ sandboxing. Low exposure levels indicate tight sandboxing and strongest security restrictions. Note that this only
+ analyzes the per-service security features systemd itself implements. This means that any additional security
+ mechanisms applied by the service code itself are not accounted for. The exposure level determined this way should
+ not be misunderstood: a high exposure level neither means that there is no effective sandboxing applied by the
+ service code itself, nor that the service is actually vulnerable to remote or local attacks. High exposure levels
+ do indicate however that most likely the service might benefit from additional settings applied to them. Please
+ note that many of the security and sandboxing settings individually can be circumvented — unless combined with
+ others. For example, if a service retains the privilege to establish or undo mount points many of the sandboxing
+ options can be undone by the service code itself. Due to that is essential that each service uses the most
+ comprehensive and strict sandboxing and security settings possible. The tool will take into account some of these
+ combinations and relationships between the settings, but not all. Also note that the security and sandboxing
+ settings analyzed here only apply to the operations executed by the service code itself. If a service has access to
+ an IPC system (such as D-Bus) it might request operations from other services that are not subject to the same
+ restrictions. Any comprehensive security and sandboxing analysis is hence incomplete if the IPC access policy is
+ not validated too.
+
If no command is passed, systemd-analyze
time is implied.