Unexpected admin@vsphere.local password changes observed inside VMware Cloud Foundation instances
- Broadcom docs and operator posts point to a real risk area in VMware Cloud Foundation: the vCenter SSO admin password can change through SDDC Manager automation. - The key detail is that `administrator@vsphere.local` is treated as SDDC Manager–managed for PSC operations, with audit traces in `ssoAdminServer.log`. - That matters because a surprise change can break access, role assignment workflows, and downstream integrations unless teams audit, alert, and keep alternate admin paths ready.
The account at the center of this story is `administrator@vsphere.local` — the built-in vCenter Single Sign-On admin. In VMware Cloud Foundation, that account is not just “a vCenter password” anymore. It sits inside a bigger credential-management system run by SDDC Manager. That is why unexpected password changes are scary here — you are not just dealing with one login breaking, you may be looking at control-plane drift across the whole stack. ### Why is this account such a big deal? `administrator@vsphere.local` is the local superuser for vCenter’s SSO domain. It is also still used for one-time setup tasks in newer VCF environments, including assigning roles after federated identity is enabled. If that password changes and nobody expected it, admins can lose their fallback path into vCenter right when they need it most. (knowledge.broadcom.com) ### What changed in VCF? VCF 9.x pushes password lifecycle management into SDDC Manager. Broadcom’s current guidance says password rotation for core components — including vCenter Server and the Platform Service Controller side of the stack — is primarily handled through the SDDC Manager interface. It also says the platform is “secure by default” and enforces periodic rotation for managed core components rather than supporting a “never expire” state. (blogs.vmware.com) ### So can SDDC Manager really own this password? Yes — and that is the crucial detail. Broadcom’s March 2026 knowledge base says `Administrator@VSPHERE.LOCAL` “is managed by SDDC Manager” for PSC password operations, and that the account cannot be used to update or rotate PSC credentials from that workflow. In plain English, the platform treats this credential as something the management layer owns, not just a local secret an operator can safely change ad hoc. (knowledge.broadcom.com) ### Why are people worried about “unexpected” changes? Because there are two very different explanations, and only one is benign. One possibility is ordinary automation — scheduled rotation, remediation, or a failed workflow retrying in the background. The other is unauthorized change or bad operational drift. The catch is that both can look similar at first: the password is different, access breaks, and dependent systems start failing. Broadcom’s own docs warn that direct CLI changes on vCenter or NSX can create compliance drift during inventory syncs or lifecycle operations. (knowledge.broadcom.com) ### How do you verify what happened? Start with the audit trail on vCenter. Broadcom documents a specific log check in `/var/log/vmware/sso/ssoAdminServer.log` for password resets, including entries showing “Resetting password of local user 'Administrator'.” That gives you a concrete way to confirm that a reset occurred and to anchor the event in time before you chase bigger theories. (knowledge.broadcom.com) ### What tends to break after a surprise reset? Anything that still depends on that local SSO admin can break first — manual login, automation, and some integration flows. Password remediation can also fail in messy ways when surrounding systems are out of sync. Broadcom has separate cases where SSO admin password remediation in SDDC Manager fails because NSX compute manager configuration is wrong, which shows how quickly one credential event can spill into adjacent management services. (knowledge.broadcom.com) ### Why mention custom roles and backups? Because identity recovery is only half the problem. In VCF 9, local admin accounts are still needed for some role-assignment tasks even after identity federation is set up. If access gets scrambled, having exported role definitions, alternate admin accounts, and recent management-plane backups can turn a lockout into a repair instead of an outage. PowerCLI and the vCenter authorization APIs are the practical tools for preserving that state. (knowledge.broadcom.com) ### What should operators do right now? Treat any unplanned `administrator@vsphere.local` password change as a high-severity control-plane event. Check SDDC Manager password policies and recent tasks, inspect the vCenter SSO audit log, verify that alternate admin paths still work, and review integrations that may have cached the old credential. If your team has been changing this account manually, stop and move the workflow back under the VCF management model. (blogs.vmware.com) ### Bottom line? This is less a mystery password story than a management-boundary story. In modern VCF, `administrator@vsphere.local` is part of an automated credential system. If that system changes the password and you were not expecting it, you need to determine very quickly whether you are seeing normal rotation, broken orchestration, or something worse. (knowledge.broadcom.com)
