Shared read-only account vs per-user server entries for Maven repository credentials

Our team authenticates to a private Nexus repository through <server> entries in settings.xml, matched by repository <id>. We want least-privilege credentials, but two documented approaches seem to conflict in practice.

Option one: a single shared read-only account per developer machine, with deploy credentials kept only in CI. This is simple to distribute and rotate, but every developer machine holds an account broader than any individual needs, and revocation affects everyone at once.

Option two: per-user accounts with separate server ids for read versus deploy, so build jobs that only resolve dependencies never see deploy credentials. This is cleaner for auditing, but multiplies settings.xml maintenance and complicates onboarding.

A related concern is expiry behavior: when credentials lapse, the repository returns 401, the build fails without prompting, and cached failure markers in the local repository can keep the build broken even after credentials are fixed, unless updates are forced. We also considered Maven's master-password encryption in settings-security.xml, but understand it is obfuscation-grade at best.

Assuming Maven 3.9.x:

• Which approach do teams actually sustain for least-privilege access without excessive settings.xml churn?
• Does separating read and deploy server ids create any resolution pitfalls when the same repository serves both?
• Is there a documented way to reduce the stale-failure-marker problem after credential rotation, beyond -U?