Can we allow one service to run scripts in /tmp without opening it up to everyone?

I would try giving the service its own view of /tmp rather than changing the host mount. A container or a dedicated mount namespace could present a separate executable filesystem at /tmp for that process tree while leaving the host's /tmp mounted noexec.

If it runs under systemd, a bind mount configured for the service may be an option. Check the mount flags inside the service and test the renewal end to end. Also limit access to the certificate files and any other host resources the service needs. Isolation does not automatically make the scripts trustworthy.

SELinux is worth looking at if the goal is to restrict execution by service identity and file type. A custom policy could confine the service and control what it can access, but the policy and labeling need careful testing, especially when the application generates new scripts.

That is a bigger job than flipping a mount option. It also does not by itself make an executable /tmp equivalent to the CIS control, so get the exception and compensating controls reviewed.

ACLs on /tmp are awkward for this. Execute permission on a directory controls traversal, so removing it from other users would stop them accessing files there, not just running scripts. Applying ACLs to existing files also misses new ones unless you have a reliable way to manage their creation.

Even then, a readable script can be passed to an interpreter such as bash or python without executing the script file directly. The same limitation applies to noexec, so be clear whether the requirement is to block direct execution or prevent script content from being run at all.

Check whether the application honors TMPDIR or has an undocumented temporary directory setting before taking the vendor's answer as the last word. If the scripts always land in one dedicated subdirectory, a separate executable mount there might also be possible. Both options still need a security review and suitable access controls.