Account sharing¶

Permit multiple people to authenticate as one nominal account by reusing its credentials or authenticators, collapsing individual identity, accountability, and revocation boundaries.

Version: v2 · 2026-09-19 · History
Domain-specific #: 1226
Domain group: Applied Sciences & Engineering
Origin domain: Computer Science & Software Engineering
Subdomains: Digital Identity, Shared Account Authentication → Computer Science & Software Engineering
Aliases: Credential sharing, Password sharing, Shared login

Core Idea¶

Account sharing is the practice in which more than one person uses the same nominal digital account by transferring or jointly using its password, one-time code, approval event, token, or other authenticator. The service consequently observes one subscriber identity even though several human actors exercise access. Sharing may be permitted, tolerated, prohibited, coerced, or informal; those policy judgments vary, while the structural identity collapse remains.^[1]

An enrolled account binds one or more authenticators to a subscriber. The subscriber discloses a secret, transfers a device, relays an approval, or maintains a common credential store so another person can pass the same verifier challenge. Authorization attached to the account then flows to every sharer. Logs attribute actions to the shared account rather than reliably to an individual, and revoking one person's access often requires rotating the common authenticator for everyone. Formal household profiles or delegated roles avoid some collapse by retaining distinct identities.^[2]

Account sharing is not secret sharing in cryptography, federation across services, an authorized multi-user account with individually attributable credentials, or ordinary content sharing after access. It can be consensual yet still weaken accountability and recovery. Conversely, not every shared subscription uses shared credentials; family plans may create separate profiles and authenticators under one billing relationship. This is a high-level defensive description, not advice for bypassing terms or controls.^[3]

How would you explain it like I'm…

One Card, Many Users

Imagine a library card with one person's name on it, and the whole family uses it with the same secret number. The library thinks just one person is borrowing everything. And if one person should stop using it, you'd have to change the secret number for everybody.

Sharing One Login

Account sharing is when more than one person uses the same online account by sharing its password, a login code or something similar. The website or app only sees one account, even though several people are really using it. That means it can't tell who did what, since everything is recorded under the one account. And to stop just one person from using it, you usually have to change the password for everyone. Some services allow sharing and some don't, and family plans that give each person their own login are different, because each person keeps their own identity.

Many People, One Identity

Account sharing is the practice of several people using one nominal digital account by passing around or jointly using its authenticator - a password, one-time code, login approval, token or similar. The service sees a single subscriber identity even though multiple people are acting through it. Whatever permissions the account has flow to every sharer, activity logs point to the account rather than a particular person, and removing one person usually means changing the shared credential for everyone. Whether sharing is allowed, tolerated, banned, pressured or informal varies, but the collapse of several people into one identity is the same in every case. It's different from a family plan with separate profiles and logins, from an account that gives each user their own credentials, and from 'secret sharing' in cryptography.

Account sharing is the use of one nominal digital account by more than one person through the transfer or joint use of its authenticator - password, one-time code, approval event, token or other credential. An enrolled account binds authenticators to a subscriber; sharing happens when the subscriber discloses a secret, hands over a device, relays an approval, or keeps a common credential store so another person can pass the same verifier challenge. The structural consequence is identity collapse: authorization attached to the account flows to every sharer, logs attribute actions to the account rather than reliably to an individual, and revoking one person usually means rotating the common authenticator for all. The policy status - permitted, tolerated, prohibited, coerced or informal - varies without changing that structure, and even consensual sharing weakens accountability and recovery. Formal household profiles and delegated roles avoid some of the collapse by keeping distinct identities, and a shared subscription is not necessarily shared credentials, as family plans may issue separate profiles and authenticators under one billing relationship. The term should also be distinguished from cryptographic secret sharing, federation across services, authorized multi-user accounts with individually attributable credentials, and ordinary sharing of content after access.

Structural Signature¶

Nominal account. One service-side identity holds entitlements and state.
Bound authenticator. A password, token, device, or approval proves access.
Primary holder. An enrolled or controlling person transfers use.
Additional user. Another person authenticates under the same nominal identity.
Shared authorization. Account entitlements become available to all successful users.
Attribution collapse. Service logs cannot reliably distinguish human actors.
Revocation coupling. Removing one sharer can disrupt every person using the credential.
Policy boundary. Terms, consent, household rules, and risk determine authorization status.

What It Is Not¶

Not delegated access. Delegation can preserve distinct identities and scoped authority.
Not family subscription. One billing plan may issue separate profiles or credentials.
Not cryptographic secret sharing. That divides a secret into threshold shares without everyone learning one credential.
Not single sign-on. One identity accesses several services rather than several people using one identity.
Not content sharing. A user may share an output without sharing account authentication.
Not account takeover. Takeover is unauthorized control; account sharing may be consensual or policy-authorized.

Scope of Application¶

The abstraction is literal wherever practitioners can identify the same constitutive roles, apply the same boundary tests, and obtain the same kind of output. The following habitats are uses of Account sharing itself, not metaphors based only on resemblance.

Consumer subscriptions. Analyzing shared credentials separately from permitted household profiles.
Enterprise systems. Identifying shared administrative or operational logins.
Caregiving and assistance. Comparing informal credential transfer with supported delegation.
Incident response. Explaining ambiguous actor attribution in account logs.
Identity design. Providing multiple users scoped credentials instead of one shared secret.
Policy analysis. Separating security, contract, accessibility, and household considerations.

Clarity¶

A clear account of Account sharing must preserve the recognition invariant stated in the Core Idea rather than rely on the title alone. State which authenticator is shared and whether separate profiles retain individual identity. Distinguish consent of the holder from authorization by the service or organization. Identify logging, revocation, recovery, and multifactor consequences. Avoid treating all household or assistive access as the same policy case. These declarations are not editorial extras: each changes what observations count, which transformations are licensed, and what conclusion can be drawn. A reader should be able to reconstruct the input, the operative rule, the output, and at least one defeater from the account without consulting an implementation or guessing an unstated convention.

Manages Complexity¶

Account sharing manages complexity by replacing a diffuse field of observations or possible operations with a bounded role structure: nominal account supplies one service-side identity holds entitlements and state.; bound authenticator supplies a password, token, device, or approval proves access.; primary holder supplies an enrolled or controlling person transfers use.; additional user supplies another person authenticates under the same nominal identity.; shared authorization supplies account entitlements become available to all successful users.. The compression is useful because it localizes disagreement. One can ask whether the input was properly formed, whether a constitutive relation held, whether an alternative explanation defeats the inference, or whether the output was overinterpreted. The same compression can mislead when its discarded detail is exactly what the decision requires. A reference-grade use therefore reports both the invariant retained and the information intentionally lost.

Abstract Reasoning¶

Identify the account owner, intended subject identity, and entitlement set.
Trace how each human user satisfies authentication.
Determine whether the service records distinct actors or one nominal account.
Compare supported delegation, profiles, and role-based alternatives.
Assess consent, policy, accessibility, and legal context separately.
Map revocation and recovery effects when one sharer leaves or a credential leaks.
Document attribution uncertainty in any audit or incident conclusion.
Test the candidate interpretation against the nearest named confusable rather than accepting a shared surface feature.
State the conclusion at the same scope as the source conditions, and retain uncertainty or nonuniqueness where the construct does not remove it.

Knowledge Transfer¶

The strict upward abstraction is Access Control. Account Sharing instantiates Access Control because multiple people obtain authorization by satisfying the verifier as one nominal account. Within shared account authentication, the full mechanism transfers literally when the same roles and boundary tests recur. Beyond that domain, only the parent-level skeleton should travel. Reusing the label Account sharing after removing its constitutive vocabulary would hide a change of mechanism behind an analogy. The honest transfer rule is therefore two-stage: recognize the domain-specific pattern first, then lift only the parent relation that remains invariant under a substrate change.

Examples¶

Canonical¶

Three workers use one administrative username and password. The system grants all the same rights and records every change under that account. After one worker leaves, rotating the credential affects the remaining two, while old logs cannot reliably identify the actor. Separate named accounts with a shared role would be delegated common authority, not account sharing in this strict sense.

Mapped back: input and conventions → constitutive role test → bounded output → explicit interpretation and defeater check.

Applied / In Practice¶

A household subscription permits several profiles but requires each adult to authenticate separately. That is not necessarily credential sharing. If everyone instead reuses one password and relays multifactor approvals, the service sees one identity. Evaluation records both service policy and the security distinction without offering a bypass method.

Mapped back: field observation or problem → candidate recognition → confusable and limit checks → appropriately scoped conclusion.

Structural Tensions¶

T1: Convenience versus accountability. One credential lowers friction but collapses attribution. Diagnostic: Test whether logs identify the acting person.
T2: Consent versus authorization. The holder may agree while policy forbids transfer. Diagnostic: Record both forms of permission separately.
T3: Shared entitlement versus shared identity. A household benefit need not require one login. Diagnostic: Check whether distinct credentials can reach the same entitlement.
T4: Accessibility versus unsupported delegation. Users may share because formal assistance paths are absent. Diagnostic: Evaluate a scoped delegated-access alternative.
T5: Revocation versus continuity. Common credential rotation disrupts all sharers. Diagnostic: Simulate removal of one user under the account design.
T6: Autonomy versus generic access control. Access Control decides authorization; account sharing specifically collapses multiple actors into one authenticated subject. Diagnostic: Give each actor a distinct credential and test whether the defining ambiguity disappears.

Structural–Framed Character¶

Multiple actors using one authenticated identity is structural; acceptability, consent, accessibility, and commercial policy are institutionally framed. The five framing criteria point in a consistent direction. Evaluative weight is limited to whether the defining conditions are met, not whether the outcome is desirable. Human practice matters to the extent that experts choose conventions, instruments, or reporting thresholds, but those choices do not make every verdict arbitrary. Institutional history explains the name and standard use; it does not replace the recognition rule. The operative vocabulary travels within the home field and closely adjacent subfields, while transfer farther away requires translation to the parent prime. Thus recognition remains disciplined even where interpretation is defeasible.

Structural Core vs. Domain Accent¶

What is skeletal. Account Sharing instantiates Access Control because multiple people obtain authorization by satisfying the verifier as one nominal account. This is the part that can be expressed without the candidate's specialist nouns.

What is domain-bound. The domain accent includes accounts, credentials, authenticators, subscribers, multifactor prompts, entitlements, audit logs, revocation, and household or enterprise policy. Remove those elements and the result is no longer Account sharing; it is only the parent relation or a loose analogy.

Why this does not clear the prime bar. The name does not recur with unchanged diagnostics across three independent domains. What transfers is already represented by Access Control. The candidate remains autonomous because its in-domain recognition rule, failure modes, and consequences are stable, but its vocabulary and interventions do not float free of the home substrate.

This entry is a kind of Access Control.

Account Sharing instantiates Access Control because multiple people obtain authorization by satisfying the verifier as one nominal account.

Relationships to Other Abstractions¶

Current abstraction Account sharing Domain-specific

Parents (1) — outgoing typed relations

Account sharing is a kind of Access Control Prime

Account Sharing instantiates Access Control because multiple people obtain authorization by satisfying the verifier as one nominal account.

Hierarchy paths (3) — routes to 3 parentless roots

Account sharing → is a kind of Access Control → is a kind of Authority

Show alternative paths (2)

Neighborhood in Abstraction Space¶

Account sharing sits in a sparse region of the domain-specific corpus (98^th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.

Family — Unclustered & Miscellaneous (2769 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-10-25

Not to Be Confused With¶

Shared account with named credentials. A system may retain actor attribution despite common resources.
Delegation. Transfers scoped authority while preserving principal and agent identities.
Secret sharing. A cryptographic threshold construction rather than password reuse.
Federated identity. One user carries identity assertions across services.
Account takeover. Unauthorized control by an intruder.
Subscription sharing. A commercial arrangement that may or may not share authentication.

References¶

[1] National Institute of Standards and Technology. (2025). Digital Identity Guidelines: Authentication and Authenticator Management, SP 800-63B-4. https://doi.org/10.6028/NIST.SP.800-63B-4 registry ↩ Show verification details

[2] National Institute of Standards and Technology. (2020, updated 2023). Security and Privacy Controls for Information Systems and Organizations, SP 800-53 Rev. 5. https://doi.org/10.6028/NIST.SP.800-53r5 registry ↩

[3] Bonneau, J., Herley, C., van Oorschot, P. C., and Stajano, F. (2012). ‘The Quest to Replace Passwords.’ 2012 IEEE Symposium on Security and Privacy, 553–567. https://doi.org/10.1109/SP.2012.44 registry ↩