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: v1 · 2026-08-30 · History
Domain-specific #: 1226
Origin domain: digital identity
Subdomain: shared account authentication
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]

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 prime: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.

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

The prospective workspace queue contains one strict upward edge to prime:access_control. No live DAG mutation is authorized.

Relationships to Other Abstractions¶

Current abstraction Account sharing Domain-specific

Parents (1) — more general patterns this builds on

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 → Access Control → Authority

Show alternative paths (2)

Neighborhood in Abstraction Space¶

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

Family — Unclustered & Miscellaneous (1565 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-09-08

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 ↩

[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 ↩