Hello,
Security scans and hardening guides often raise concerns about system accounts such as daemon, lp, sshd, dbus, and mail because the usual system-wide password policy does not control how their passwords are created or how complex they are.
Thanks, Sohail 
Hi, Security hardening benchmarks, such as those from the Center for Internet Security (CIS), often include checks that can wrongly flag system accounts based on password age or complexity. For these accounts, the better control is to disable them for authentication instead of applying password rules meant for human users.
The usual password policy requirements, such as complexity and aging, should not be enforced on system accounts because they add little value, are not needed, and can create problems for configuration management.
The proper and required security control for non-interactive system accounts is to make sure they are explicitly locked down using the following two measures:
Set the shell to /sbin/nologin or a similar non-interactive shell. This stops the account from being used for interactive logins, such as SSH or a local terminal session, no matter what the password state is.
Below is an example of how this would appear in the /etc/passwd file on a CentOS system, showing the /sbin/nologin shell:
daemon:x:2:2:daemon:/sbin:/sbin/nologin
The most important step is to make sure the password hash field in /etc/shadow is set so that password-based login is not possible. This is achieved by locking the account’s password.
Use the passwd -l command to lock the account. It adds an exclamation mark (!) to the existing password hash, which prevents it from being used for authentication.
Action:
For non-root system accounts with a UID below 1000, except for sync, shutdown, and halt, make sure they are locked.
Example: Locking the 'daemon' account
sudo passwd -l daemon
/bin/sync, /sbin/shutdown, and /sbin/halt are intended for specific system operations and are not used as interactive login shells.
Julia