Managing Passwords in VCF 9.1

In VCF 9.0 you could change a password. In VCF 9.1 you can write a rule and have the fleet hold to it.

That is the whole difference in one line, and it is a bigger change than it sounds, because a policy is an object you assign rather than an action you run.

The short version

VCF 9.1 adds password policies. Length, complexity, history, expiration and lockout, bundled into a policy you assign at fleet, management component or instance level. There is no equivalent in VCF 9.0.

SDDC Manager is on its way out, and the docs now say so. Not implied, stated: "SDDC Manager will be deprecated in a future VCF release."

CyberArk turns up. VCF Operations can sit in front of a CyberArk vault through a marketplace integration.

What VCF 9.0 gave you

The VCF 9.0 page describes three actions.

Action	What it does	Where you do it
Update	Changes the password on the server side and on the client side	VCF Operations
Remediate	Resynchronises after someone changed a password on the server directly	VCF Operations
Rotate	Changes to an auto generated password on both sides	SDDC Manager

It covers the management components, Fleet Management, VCF Automation, VCF Identity Broker, VCF Operations, VCF Operations for Logs and VCF Operations for Networks, plus the instance components, ESX, NSX Manager, vCenter and SDDC Manager, where only the backup password is in scope.

One operational detail from the VCF 9.0 page that is easy to trip over: password information in VCF Operations is refreshed once a day. If you need the current state rather than yesterday's, you have to ask the API.

Notice what is not on that list. There is no way to say "every account in this fleet must be fifteen characters and expire in a year". You can change passwords. You cannot govern them.

What a VCF 9.1 policy actually controls

This is the part worth knowing before you design anything, because the defaults are opinionated and the ranges are narrower than people expect.

Attribute	Default	Allowed range
Minimum length	15 characters	8 to 64
Required character types	1 uppercase, 1 lowercase, 1 numeric, 1 special	n/a
Password history	Rejects the previous 5	1 to 10
Expiration	365 days	30 to 730
Account lockout	3 failed attempts	0 to 5
Lockout evaluation window	900 seconds	300 to 1800
Lockout duration	900 seconds	600 to 1800

Fifteen characters as the default minimum is the one to flag to whoever owns your standards document. It is above what a lot of existing policies ask for.

Where the passwords actually live

This is the part that changes how you think about the platform, and it is easy to miss because it is spread across two pages.

SDDC Manager keeps a copy. The documentation is blunt about it: "SDDC Manager stores a copy of an account password in a local, internal vault." That vault is why a password changed directly on a component causes trouble. In the docs' words, doing so "causes a mismatch between SDDC Manager's vault and the new password, and requires a remediation step, before the inter-component communication can be restored." It is also why SDDC Manager can show you a credential: there is something stored to show.

VCF Operations does not. The VCF 9.1 documentation states it in one sentence: "VCF Operations does not store a copy of an account password in a local vault."

That is not a detail, it is the design, and the docs spell out why it matters: "changing an account password where the account resides does not affect the ability of VCF Operations to update that password (on both the client and the server)."

Put the two behaviours side by side and the contrast is sharp. Change a password directly on a component and SDDC Manager's vault is out of step, which is now a problem you have to go and fix. Do the same thing with VCF Operations and nothing breaks, because there was never a second copy to fall out of step with.

That is the real shift in VCF 9.1. The preferred path stops being a credential store and becomes a control plane. You get policy, compliance and alerting, and in exchange the platform is no longer the thing you go to when you have forgotten a password.

Two consequences worth planning for:

• If you have been treating SDDC Manager as your password lookup, that habit has a deadline. The lookup still exists in VCF 9.1, but SDDC Manager is going away, and VCF Operations is not a replacement for it in that respect.
• Decide where credentials will actually live. This is precisely the gap the new CyberArk integration fills. VCF Operations sits in front of the vault as a gateway rather than becoming the vault itself.

One detail that fits the same pattern: in VCF 9.1, SDDC Manager's own root and vcf accounts are listed as managed manually through the OS, not by the platform.

Where a policy applies, and which one wins

A policy can be assigned to the entire VCF fleet, to the VCF management components, or to an individual VCF instance. Every fleet object carries one active policy.

When two of them overlap, the narrower one wins: "The instance-level policy takes precedence over the fleet-level policy."

From VCF 9.1.1, removing an instance level policy drops that object back to the fleet policy rather than leaving it unmanaged, which is the behaviour you would want and worth knowing you now get.

Five things that will bite you

Expiration and lockout apply the moment the policy does. They are not phased in on the next password change.

A password older than the new expiry expires immediately. If the last update was N+1 or more days ago and you apply a policy with an N day expiry, that account expires on apply, not at some future date. Apply a 90 day policy to an estate nobody has touched in six months and you will find out quickly.

Wait half an hour after deploying management services. Straight from the docs: "Password policy operations might fail if they are started right after VCF management services deployment completes. After deployment, the Salt RaaS component requires approximately 30 minutes to establish connections to all managed nodes."

Non-expiring accounts are left alone by default. Expiration and lockout are not enforced on them unless you go to the API and say otherwise. That default exists to protect upgrades, which means an upgraded fleet is quieter than you might assume. If you are chasing strict compliance, this is the gap to go and close deliberately.

In VCF 9.1.1, updating the password of a locked account does not unlock it. The lock raises an alert in VCF Operations, and you can still update the password, but the account stays locked. Those are two separate problems to solve.

The documentation itself tells the story

I checked which child pages exist under Managing Passwords in each release. The structure is the clearest summary of the change.

Child page under Managing Passwords	VCF 9.0	VCF 9.1
Default password requirements	Yes	Yes
Update passwords	Yes	Yes
Reset passwords	Yes	Yes
Passwords and certificates container	Yes	Yes
Password policies	No	Yes
Using SDDC Manager to manage passwords	No	Yes

Two new pages, and they point in opposite directions. One introduces the thing you are meant to use from now on. The other gathers the SDDC Manager material into a single place and tells you it is going away.

So what should you actually do

If you are on VCF 9.0, keep using update and remediate, and keep in mind the once a day refresh when something looks stale.

If you are on VCF 9.1, write a policy and assign it at fleet level first, then override at instance level only where you have a real reason. Check your estate for accounts that have not been touched in a while before you set an expiry, because of the N+1 behaviour above. And if compliance matters, decide consciously about non-expiring accounts rather than inheriting the quiet default.

Either way, anything you have built around SDDC Manager for passwords now has a shelf life.

Sources

• Managing Passwords for VCF Components, 9.1
• Password Policies in VCF, 9.1
• Managing Passwords, 9.0

Checked on 1 October 2026. Defaults and ranges do get revised between releases, so confirm against the page for your exact build before you commit a policy to a change window.