It really depends. There's honestly a really big difference between user and root on Linux, so handing root over is probably not ideal. That said, how you deal

It really depends. There's honestly a really big difference between user and root on Linux, so handing root over is probably not ideal. That said, how you deal with this is up to you and very specific to your infrastructure and security posture. For example, the obvious question is probably "why is anyone sudo'ing". A lot of operational capabilities don't need sudo. Some do. Rather than handing over passwordless sudo, you can provide binaries that can execute with the required permissions but provide a much more granular interface. For example, if you need to take a memory dump of a service the binary could be set up to only allow that capability and to only work on a set of services. Further, you may want to audit sudo access but allow it. If you remove the need for root capabilities for engineering purposes you should see sudo very rarely and be able to alert on that - but obviously this assumes you have an instrumentaiton pipeline set up. Speaking of instrumentation, it's one of the major reasons why you don't want to just hand root over. An attacker with root can more or less just turn instrumentation off. An attacker without root is auditable. For your specific situation your current security posture could be fine. For a large company they may want to do more. The tl;dr is really that, yeah, on some default Linux system where you assume an attacker is executing within your user already, a password on sudo isn't gonna help much. But obviously you should harden that server, and a big part of that is going to be "how do I keep the attacker from getting root".