Security isn't an "on" or "off" thing. Each individual measure you take in the hope of improving security also has a cost, and the value of the improvement in security needs to be weighed against that cost.

As an extreme example, turning off your servers and locking them in a vault will make them considerably more secure. Yet, if your customers can't access your servers to buy things from you and you can't access them to sell things, your company won't have any revenue and the overall benefit will be (very) negative.

So as a security engineer you need to to consider not just how to make things more secure but do risk analysis and risk management: understand what risks you're taking, why, the potential downsides, and the cost of the measures to fix them. You should regularly find yourself saying, "yes, this bad thing could happen with some probability, but it's more cost effective to run that risk than to try to mitigate it further."

For your jump host, if you're surprised by the reaction of the people who need to access that server you missed something in your analysis. (You can't do a risk-benefit analysis if you don't know how much implementing a particular measure will make the users' jobs easier or more difficult.) You need to try to find out before you implement a security measure how much harder it will make users' lives. And once you've worked that out, and why it makes things harder, you're also in a better position to implement mitigating measures.

Using the example of a jump host, not allowing direct login might mean not only that users have to type an ssh command twice but also that copying files back or forth (say, to pull a backup out of the system) becomes more difficult. You might be able to mitigate this by preparing an entry for their SSH config files that uses ProxyCommand to set things up so they can still use a single SSH command just as they used to do.

Showing that you're considering how your changes affect other people's jobs will probably go a long way toward making your changes more acceptable to them.

Security isn't an "on" or "off" thing. Each individual measure you take in the hope of improving security also has a cost, and the value of the improvement in security needs to be weighed against that cost.

As an extreme example, turning off your servers and locking them in a vault will make them considerably more secure. Yet, if your customers can't access your servers to buy things from you and you can't access them to sell things, your company won't have any revenue and the overall benefit will be (very) negative.

So as a security engineer you need to to consider not just how to make things more secure but do risk analysis and risk management: understand what risks you're taking, why, what bad things could happen and their probabilities, and the cost of those bad things should they happen. You should regularly find yourself saying, "yes, this bad thing could happen with some probability, but it's more cost effective to run that risk than to try to mitigate it further."

For your jump host, if you're surprised by the reaction of the people who need to access that server you missed something in your analysis. (You can't do a risk-benefit analysis if you don't know how much implementing a particular measure will make the users' jobs easier or more difficult.) You need to try to find out before you implement a security measure how much harder it will make users' lives. And once you've worked that out, and why it makes things harder, you're also in a better position to implement mitigating measures.

Using the example of a jump host, not allowing direct login might mean not only that users have to type an ssh command twice but also that copying files back or forth (say, to pull a backup out of the system) becomes more difficult. You might be able to mitigate this by preparing an entry for their SSH config files that uses ProxyCommand to set things up so they can still use a single SSH command just as they used to do.

Showing that you're considering how your changes affect other people's jobs will probably go a long way toward making your changes more acceptable to them.