Why is the password LCP subordinate to the account LCP, and what follows from that?

A password only exists as part of an account: it cannot be created before the account and must disappear with it, so every password operation runs inside the account's life cycle, even though it has its own triggers.

"Subordinate" (untergeordnet) means a strict dependency:

• Create: a password is created together with, or after, its account. In the webshop that happens in two ways: a self-registering customer chooses one, or, when sales creates a brand-new user via the CRM, the provisioning assigns an initial password.
• Update: the user changes or resets the password. This touches neither the account data nor the company.
• Delete: when the account is deleted, the password goes with it. A password without an account would be a dangling credential.

So why a separate LCP at all? Because its triggers, actors and security rules differ completely from the account's. Account data is maintained by sales or the customer; the password is changed only by its owner, at any time, through self-service, and must never be visible to sales staff. An initial password is a special risk: it is created by the system and has to reach the user over a safe channel. Many systems also ask the user to replace it at first login; NIST permits passwords assigned randomly by the provider, so this is a policy decision the password LCP has to make explicitly.

The dependency also tells you what to check when coordinating the processes: whenever the account LCP creates or deletes a user, ask what the password LCP must do at that moment.

Go deeper:

• NIST SP 800-63B: Passwords — current requirements for choosing, storing and verifying passwords.
• Self-service password reset (Wikipedia) — the typical way the "update" step of a password life cycle is handed to the user.