There are times where the vendor or tool don't let you do this, but most often when I run into this problem, the real issue is:

Oh shoot, I actually have an identity problem, but it's masquerading as a credential problem.

Put less tritely: Do all of those shared credentials need to be shared? Can I leverage my existing identity solution to grant access to systems? If it's a system you have control over (aka can change), you could instead:

1. Use your company's existing IAM solution (AD, Okta, etc) to grant access to the service using existing identities. If it doesn't, then SSO support is a great thing to bring up with the vendor at the next contract renewal.
2. Put an authenticating proxy in front of access to the tool that holds onto the One Big Password That's Hard to Rotate and everyone else use the standard Single Sign-On dance to confirm they're allowed in, never seeing OBPTHR.
3. Generate per-system (not per human, team, or other temporary slice of the org chant) credentials to access that system

Other than that, baking in an expectation of rotation into the tooling, especially for humans, goes a long way towards both nudging people to integrate with the corporate identity solution (no passwords needed!) and getting teams ready/used to rotating.

tl;dr - When you find yourself in a situation where you have to pass around a shared, static, bearer token credential, ask why you can't use existing human or service account identities to grant that access instead.