A city CI server's service account allows interactive logon and uses a weak password. Why is that risky?

A city CI server’s service account that allows interactive logon and uses a weak password is risky because powerful service accounts with weak credentials and unnecessary interactive logon are prime targets for takeover and lateral abuse. Service accounts should not always allow interactive logon for troubleshooting; that right expands how stolen credentials can be used on municipal hosts. CI accounts are not inherently low privilege—pipelines often touch repos, secrets, and deploy targets—so password strength is not optional. Interactive logon rights do not cancel weak passwords through Windows defaults; the combination worsens impact. Exam caveat: report both the privilege/logon right issue and the credential strength issue as related control failures. Operational check: identify the account’s group memberships and logon rights, demonstrate weak credential risk within RoE without disruptive lockouts, recommend gMSA or vaulted strong secrets, deny interactive logon, and least-privilege the CI identity to required deploy actions only. In municipal operations, record the rationale in the engagement notes so future testers and city defenders understand which approach was chosen and which failure modes the rejected options would create for civic services.