Replace Shared Logins Without Blocking the Team

Start with the capability, not the shared credential

This guide concerns shared login credentials and access paths—not joint bank-account ownership, shared inbox products, team workspaces, or generic collaboration features. Define the business capability first: what bounded work must continue, who is authorized, and how much interruption the business can tolerate.

NCSC password-manager guidance says password sharing between individuals is not recommended, while recognizing that some organizations cannot yet use alternatives such as delegated privileges or alternative authentication methods. Where sharing remains, it recommends distinguishing shared from individual passwords, logging access to the shared password, and giving an authorized person control over access. NCSC identity and access guidance supports binding an identified user to an identity, least privilege, lifecycle decisions, and appropriate audit records.

Those sources support controlled access, attribution goals, least privilege, audit considerations, and revocation. They do not prescribe the six outcomes, seven stages, workflow labels, 17 fields, exception threshold, or fictional example below. Those are PlainFort editorial choices—not NCSC requirements, legal or licensing conclusions, certification, proof of attribution, a security guarantee, or a universal migration plan.

Separate six layers that sharing tends to blur

1. Business capability needed — the bounded work, separate from the credential.
2. Identity and account model — individual, delegated, brokered, controlled shared, exception, or unknown.
3. Authorized user set — roles allowed to use the path and confidence the set is complete; no identities.
4. Secret visibility — human-visible, mediated, not applicable, or unknown; never the secret itself.
5. Attribution and evidence — what distinguishes a person, retrieval, provider action, or local record, and what remains anonymous.
6. Revocation and continuity behavior — how one person’s access ends and essential work continues, based on documentation.

Shared account, shared inbox, joint account, team account, delegated access, password sharing, and controlled shared access are not interchangeable.

Controlled shared access remains shared use. A retrieval log does not automatically prove who performed a later provider-side action. A provider log does not prove the secret was never exposed elsewhere. Use Documented, Observed in non-secret record, Unknown — follow up, or Not supported by available evidence rather than implying hands-on testing.

Use seven stages for one bounded decision

The sequence, states, order, exception threshold, artifact, and completion test are PlainFort editorial judgment.

1. Bound the capability and interruption risk

Describe the task, business need, impact, internal owner, authorized roles, privilege, and acceptable interruption without opening or recording the credential.

2. Describe the current sharing state safely

Record non-secret references for the service, identity model, user-set confidence, secret visibility, attribution, revocation, recovery, and unknowns. Not recorded is different from none.

3. Check provider-supported alternatives

Use current primary documentation for individual access, delegation, brokering, controlled sharing, audit, recovery, provisioning, revocation, and licensing. Do not test or infer a feature.

4. Walk the six outcomes in order

Record why every earlier outcome is feasible, rejected, unknown, or blocked before choosing a later one.

5. Prepare continuity before change

Identify backup ownership, surviving access, last-administrator or sole-path risk, AA-06/07/08 dependencies, stop conditions, and escalation. Perform no live change.

6. Record the selected pattern or exception

Preserve accountability, authorized roles, secret-visibility boundary, evidence limits, expiry or exit, residual risk, and dependencies. Selected means awaiting separately authorized implementation.

7. Verify on paper and schedule review

Inspect primary documentation and non-secret evidence. Route implementation and departure revocation to the owning guides. Reopen on provider, user-set, privilege, recovery, licensing, business-impact, or threat change.

Walk exactly six outcomes

The outcomes are not equivalent or a product ranking. Stop at the first outcome that is feasible, authorized, documented, and sufficient.

1. Eliminate the access need

Remove an obsolete capability from the future design when the work is no longer required. Do not delete data, disable access, or interrupt an integration blindly.

2. Use individual accounts

Prefer separately identified access where supported and authorized. Record attribution, privilege, provisioning, recovery, revocation, continuity, and unresolved licensing questions.

3. Delegate within the service

Use a documented provider-supported delegation model that preserves separate identities. Do not assume delegation exists, carries the required privilege, produces adequate evidence, or survives recovery and offboarding.

4. Broker access without revealing the secret

Use a documented mediated path only when current primary evidence supports it. Secret visibility, attribution, fallback, recovery, audit, provisioning, revocation, and licensing remain separate questions.

5. Use controlled shared access

If earlier outcomes are unavailable, constrain who may retrieve or use the shared credential and preserve whatever evidence the real system supports. It remains shared use and does not create individual provider identities.

If selected, AA-06 owns the later rollout. AA-10 does not define vault structure, migrate the credential, execute recovery, handle legacy storage, or copy or move the secret.

6. Retain a bounded exception

Keep sharing temporarily only when earlier outcomes are documented as unavailable or unsafe now. Record owner, authorized roles, privilege, secret visibility, continuity, provider constraint, evidence, expiry or exit, residual risk, escalation, and review.

No expiry, Unknown users, Unknown owner, Terms unclear, No safe continuity path, and Provider behavior unverifiable are escalation states, not completed exceptions.

Do not select a later outcome merely because it is cheaper or easier if it violates provider terms, licensing, law, contract, or access controls. This article does not determine legal or contractual permissibility and must not teach licensing avoidance, impersonation, control bypass, provider-restriction defeat, or identity misrepresentation.

Stop before changing access or losing continuity

Before any separately authorized live replacement or removal, confirm:

• an accountable internal owner and authorized executor;
• the interruption boundary and surviving access path;
• whether this is the last administrator, root, financial, production, emergency, or recovery path;
• the authorized user set and any unknown user;
• current provider documentation and unresolved terms or licensing questions;
• AA-06 rollout dependency for controlled sharing;
• AA-07 method, fallback, and recovery dependency;
• AA-08 privilege and separation dependency for administration;
• how AA-09 can later remove one person’s access;
• whether qualified product, IT, security, legal, contractual, financial, or incident help is required.

Do not disable, delete, rotate, import, export, reveal, or test access; remove the last administrator; execute recovery; close sessions; or perform offboarding. Suspected compromise belongs in incident guidance.

Break-glass is a separate narrowly governed emergency-access pattern, not an informal shared login or permanent exception. It requires purpose, internal owner, authorized roles, protected storage outside this article, access control, logging where available, review/test trigger, post-use review or rotation where applicable, and expiry or exit. This guide does not create, configure, reveal, or test it.

Keep sibling decisions separate

AA-06 owns rollout, vault structure, migration, recovery readiness, adoption, and legacy-storage handling after AA-10 selects an outcome. AA-10 neither repeats those stages nor copies or moves a secret.

AA-07 owns MFA properties, fallback, device loss/replacement, accessibility, and recovery tradeoffs. Do not solve sharing by sharing a phone, security key, OTP seed, recovery code, QR material, or another authenticator. Record AA-07 decision required and stop.

AA-08 owns everyday/administrator separation, privilege, elevation, and administrative exceptions. AA-10 does not design administrative roles or normalize a shared administrator.

AA-09 owns the departure trigger, effective time, authority, action order, session handling, evidence, exceptions, and closure. AA-10 records expected revocation behavior but does not execute offboarding.

SF-05 owns operational vendor-access fields. A provider does not implicitly acquire the team’s internal accountability.

Use a 17-field vertical decision record

Use one vertical block per decision, not a wide table.

1. Bounded business capability and non-secret service reference — no username, endpoint, or credential.
2. Internal accountable owner — a role; not proof of competence or authority.
3. Authorized user roles and current user-set confidence — no identities.
4. Current identity/account model — individual, shared, delegated, brokered, exception, or unknown.
5. Privilege and business-impact boundary — no sensitive configuration.
6. Current secret-visibility state — human-visible, mediated, unknown, or not applicable.
7. Current attribution and evidence limit — person, retrieval, action, local record, and uncertainty kept distinct.
8. Continuity requirement and acceptable interruption — surviving path, backup, and stop threshold.
9. Current revocation and recovery behavior — categories and authority only.
10. Provider documentation checked and date — primary source, not a hands-on finding.
11. Outcome 1 — eliminate access need — feasibility, authority, dependencies, and reason.
12. Outcome 2 — individual accounts — availability, attribution, privilege, revocation, and terms uncertainty.
13. Outcome 3 — delegated access — documented behavior, evidence, constraints, and unknowns.
14. Outcome 4 — brokered access — mediation, secret visibility, attribution, fallback, and limitations.
15. Outcome 5 — controlled shared access — user control, retrieval evidence, shared-use limitation, and AA-06 dependency.
16. Outcome 6 — bounded exception — owner, roles, reason, scope, expiry/exit, residual risk, and escalation.
17. Selected outcome, dependencies, completion evidence, escalation, and next review trigger — decision plus unresolved implementation.

States include Candidate, Selected — implementation not authorized, Not feasible — reason recorded, Unknown — provider behavior, Blocked — licensing or terms unclear, Blocked — last administrator, Blocked — continuity unresolved, AA-06 implementation required, AA-07 decision required, AA-08 decision required, AA-09 revocation dependency, and Exception — expiry required. They are workflow labels, not scores or proof of security.

Fictional example — do not copy as a completed shared-login decision

Example Co. is reviewing the invented ExampleDesk support capability. It contains no real provider, person, account, credential, endpoint, financial detail, licensing record, access log, configuration, or hands-on result.

1. Bounded business capability and non-secret service reference: ExampleDesk — support continuity — Reference S-01.
2. Internal accountable owner: Operations lead; competence and contractual authority remain separate.
3. Authorized user roles and current user-set confidence: Two support roles expected — user set incomplete.
4. Current identity/account model: Shared login — existing state described, not opened or tested.
5. Privilege and business-impact boundary: Respond to support requests; financial, administrative, export, and configuration capabilities are excluded and unverified.
6. Current secret-visibility state: Unknown — follow up; the secret is not recorded, viewed, or moved.
7. Current attribution and evidence limit: Local role list exists; no evidence identifies who performed a provider-side action.
8. Continuity requirement and acceptable interruption: Business-hours continuity required; no surviving alternative is documented.
9. Current revocation and recovery behavior: Unknown — provider behavior; no action occurs.
10. Provider documentation checked and date: Invented document D-01 — date recorded; no real provider claim.
11. Outcome 1 — eliminate access need: Not feasible — capability remains required; no deletion proposed.
12. Outcome 2 — individual accounts: Candidate — documentation incomplete; terms, privilege, and revocation unverified.
13. Outcome 3 — delegated access: Not feasible — no support found in the invented document; limited to fictional evidence.
14. Outcome 4 — brokered access: Unknown — provider behavior; no feature inferred.
15. Outcome 5 — controlled shared access: Candidate — AA-06 implementation required; remains shared and no secret is moved.
16. Outcome 6 — bounded exception: Exception — expiry required; operations lead owns a short review window while attribution and continuity risks remain.
17. Selected outcome, dependencies, completion evidence, escalation, and next review trigger: No implementation selected; gather primary documentation for Outcome 2, retain AA-06 and AA-09 dependencies, escalate unclear terms or users, and review at exception expiry or provider, role, privilege, recovery, or impact change.

The example rejects Outcomes 1 and 3, leaves Outcomes 2 and 4 unresolved, and stops before live change. It does not claim provider capability, licensing permission, audit completeness, successful revocation, or secure access.

Know what completion means

A decision is complete only when capability, owner, roles, identity model, privilege, secret visibility, attribution limits, continuity, revocation/recovery, documentation, all earlier outcomes, selected result or exception, dependencies, evidence, escalation, and review trigger are recorded truthfully.

Completion does not mean implementation occurred. It does not prove provider behavior, individual attribution, audit completeness, legal or contractual permission, successful recovery or revocation, endpoint integrity, continuity, or security.