Replace Shared Logins Without Blocking the Team

Choose access for the work the team needs

Start with the task the team needs to perform. Sharing a support inbox does not necessarily mean sharing a login; access through separate identities, delegation and one password known by several people are different arrangements. Check what the actual service supports before choosing a replacement. This guide concerns login credentials and access paths, not joint bank-account ownership, shared-inbox product selection, team workspaces or general collaboration features.

This guide helps you choose an access pattern without interrupting essential work. It does not configure a service, move credentials or settle licensing questions. The NCSC password manager buyers guide advises against password sharing while recognizing that some organizations cannot yet use alternatives. Controlled sharing remains shared use; it does not become individual provider access.

Choose an access pattern

For each option, record whether it is feasible, unavailable or still unknown; an unknown is not a reason to assume the next option is safe.

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, plan a password-manager rollout as a separate implementation step. The shared-login guide 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.

Fictional planning example: a small support team needs two roles to answer incoming requests. The business task must continue, so eliminating access is not a candidate. The team checks whether its service supports separate identities or delegated access; neither capability is assumed. If documentation is inconclusive, the decision remains open. An existing shared login is not silently moved into a vault or called safe. Its owner must resolve continuity and permitted use before any change.

Check what the pattern actually gives you

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.

Prepare the decision before changing access

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, rollout, MFA and administrator-account decision 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.

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;
• The rollout dependency for controlled sharing;
• The MFA guide method, fallback, and recovery dependency;
• The administrator-account guide privilege and separation dependency for administration;
• how the offboarding checklist 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.

Related access decisions

The password-manager rollout guide owns rollout, vault structure, migration, recovery readiness, adoption, and legacy-storage handling after the team selects a shared-login outcome. The shared-login guide neither repeats those stages nor copies or moves a secret.

Use the MFA guide to review MFA and recovery choices, including fallback, device loss/replacement and accessibility. Do not solve sharing by sharing a phone, security key, OTP seed, recovery code, QR material, or another authenticator. Record MFA decision required and stop.

Use the administrator-account guide to separate administrator access, including privilege, elevation and administrative exceptions. The shared-login guide does not design administrative roles or normalize a shared administrator.

Use the offboarding checklist to coordinate employee access offboarding, including the departure trigger, effective time, authority, action order, session handling, evidence, exceptions and closure. The shared-login guide records expected revocation behavior but does not execute offboarding.

The vendor-access register 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 the rollout 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, Rollout implementation required, MFA decision required, Administrator-account decision required, Offboarding 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 — Rollout 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 the password-manager rollout guide and the offboarding checklist 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.

The NCSC identity and access guide discusses identifying users and managing access through their lifecycle. It does not establish that any service offers these six options. Those are PlainFort editorial choices, not provider capability or legal conclusions.