Service accounts and password managers - are we solving the wrong problem

Been thinking about this lately because we've got a bunch of service accounts just sitting in our org's password vault and it feels wrong. Technically the credentials are "managed" but we're not actually fixing the underlying issue. The more I dig into it the more it seems like trying to extend a human-oriented password manager, to cover service accounts is mostly kicking the can down the road rather than solving the real problem. The tiered approach makes more sense to me: gMSA handles automatic rotation for supported Windows domain services, managed identities remove the credential entirely for cloud-to-cloud workloads, where the platform can issue the identity for you, and something like Azure Key Vault or HashiCorp Vault can supply secrets at runtime for everything else. The password vault ends up being a fallback for legacy apps that genuinely can't support any of those patterns, and honestly that's still a legitimate use case. I'm not saying vaults are useless here, just that they're the last resort tier, not the strategy. The part I'm still working through is dependency management when you do have to rotate. Keeping IIS app pools, scheduled tasks, and scripts in sync is where things tend to break in practice. I haven't found a clean answer that doesn't involve a proper PAM tool doing the, dependency tracking, and even then you're relying on that inventory being accurate, which it usually isn't. Curious if anyone has actually gotten gMSA to a meaningful coverage percentage in a mixed, environment, or if you're mostly relying on vault-fetched secrets for the workloads that won't support gMSA. Also interested in how people are handling the non-Windows and on-prem cases where neither gMSA nor managed identities are an option.