Households share outcomes: a calendar, photo archive, streaming plan, utility account, smart-home system or set of bills. The shortcut is to share one username, one password and one recovery phone. That turns several people into one digital identity—and turns one credential failure into a household failure.
The better design uses individual identities where the service supports them, grants only the role each person needs and preserves a recovery path for the resource owner. It is not zero trust inside a family. It is legible trust: people can help without silently inheriting private data, purchase authority or the ability to lock everyone else out.

Start with resources, not passwords
List the things people need to do, not the credentials you currently pass around. “View the family calendar,” “upload photos,” “change the thermostat,” “pay the utility bill,” “download tax records” and “recover the primary email” are different capabilities. Combining them because they happen to live behind one account gives everyone the highest privilege needed by anyone.
For each resource, name the owner, people who need routine access, people who need emergency access and actions with financial, privacy or safety consequences. Record whether the service offers individual members, family sharing, delegated access, guest access, read-only links or separate administrator roles.
Do not put passwords, recovery codes or security answers in this inventory. Point to an approved password-manager item, secure offline record or official recovery process. The inventory is a map of authority, not a second credential store.
Use the smallest useful role
NIST defines least privilege as restricting a user or process to the minimum resources and authorizations needed for its assigned task. That principle was written for information systems, not household etiquette, but it scales down cleanly.
| Household need | Preferred route | Avoid by default |
|---|---|---|
| Consume shared media | Individual family profile or member account | Primary account owner password |
| Add to a photo collection | Shared album with named contributors | Full cloud-library login |
| See appointments | Shared calendar or delegated calendar access | Sharing the owner's email identity |
| Control a home device | Household member or guest role | Vendor administrator credential |
| Pay a bill | Authorized payer, bank bill pay or documented owner process | Email, bank and utility credentials bundled together |
| Emergency recovery | Offline recovery package with explicit trigger | Permanent daily administrator access |
The preferred route is not always available. Old devices and small services may offer only one account. When that is true, contain the exception: limit the account's scope, use a unique credential, enable supported multifactor authentication, store the shared item in a reputable password manager and document who can rotate or recover it.
Family plans are boundaries, not magic
Apple's current Family Sharing documentation says up to six people can share eligible services without sharing an Apple Account. Google family groups likewise let members share selected services while keeping individual Google Accounts; Google notes that storage usage can be visible while files themselves are not automatically shared. These are examples of an architectural pattern, not endorsements of either ecosystem.
Read the exact service rules. “Family” may expose names, email addresses, purchases, location, storage usage or a shared payment method. A plan may restrict country, age, family-switching frequency or the number of members. Sharing a subscription does not mean every data type is shared, and joining a family group is not equivalent to consenting to every optional feature.
Use official invitations and verify the account that accepted. Never paste credentials into a message because the invitation flow seems inconvenient. For children or supervised accounts, follow current platform and legal requirements; do not evade age controls by making a child appear to be an adult.
Separate routine access from recovery authority
The person who can read a shared calendar does not need the recovery codes for the email account that owns it. The person who can adjust a thermostat does not necessarily need authority to remove every household member. Keep recovery at a higher, narrower layer.
For critical resources, record the account owner, recovery email or phone, multifactor method, location of offline recovery codes, billing owner, renewal path and the person authorized to act if the owner is unavailable. Store this record securely and tell the authorized person where it is. Test only the safe parts: confirm that the record exists, links still point to official pages and recovery factors are current. Do not trigger a destructive recovery on a production account just to prove confidence.
One phone number should not be the sole recovery route for every essential account. Loss of the device, number reassignment or an account lockout can cascade. A personal dependency map makes that common root visible.
Multifactor authentication belongs to identities
CISA recommends multifactor authentication because a stolen password alone is then insufficient. In a multi-person system, the second factor must not become a hidden sharing trap. If every login depends on one person's phone prompt, other members do not have independent access; they have a real-time dependency on that person.
Prefer member accounts with their own factors. For the rare shared credential, determine which authenticators the service supports, whether multiple security keys or passkeys can be enrolled, what happens when one is removed and how backup codes are governed. Never duplicate a biometric or encourage people to approve unexplained prompts.
Design the exit while everyone is still cooperative
Households change. A child becomes an adult. A roommate moves. A caregiver's role ends. A relationship becomes unsafe. The access design must support removal without erasing another person's data or taking away purchases they own.
Before granting access, write the offboarding action: remove the member, transfer ownership, export contributed files, change a shared credential, revoke devices, preserve legally required records and verify that billing responsibility moved. For sensitive or coercive situations, use the platform's personal-safety guidance and qualified local help; do not announce access changes if doing so could increase danger.
Review shared access after a move, device loss, relationship change, death, new child account, caregiver transition or security incident. A yearly review is a useful floor, not a reason to wait after a triggering event.
The 30-minute shared-access protocol
- Choose one shared resource with real consequence.
- Name the owner and the actions each person actually needs.
- Open the official role, family or delegation documentation.
- Create or confirm individual accounts; do not reuse another person's identity.
- Grant the smallest supported role and disable optional sharing.
- Enroll each member's own authentication factor where supported.
- Document the recovery owner and secure location of recovery material.
- Test one ordinary task from each role without using the owner's credential.
- Write the offboarding action and next event-triggered review.
If the service supports no safe sharing model, decide whether the shared outcome is worth the credential risk. Sometimes the correct answer is a different service, a read-only export, a local paper copy or no sharing at all. The personal threat-model worksheet helps size that decision without buying every security product.
Boundaries and safety
This guide is general digital-hygiene guidance, not legal, financial or domestic-safety advice. Banks, health portals, government accounts and employer systems may prohibit credential sharing and provide specific authorized-access procedures. Use those procedures. Do not impersonate an account holder, bypass access controls or treat possession of a password as legal authority.
Sourced fact: major ecosystems provide mechanisms for sharing some services across individual accounts, and least privilege limits access to what a role needs. Inference: household systems are more recoverable when identity, routine access and emergency authority are separate. Judgment: the appropriate boundary depends on the resource, relationships and harm model. Not promised: separate accounts cannot eliminate coercion, provider failure or every privacy leak.
Official sources and further reading
- NIST CSRC Glossary: Least Privilege, for the access-control principle adapted here.
- CISA Secure Our World: Turn On MFA, for current consumer authentication guidance.
- Apple Support: Set up Family Sharing, checked September 26, 2026.
- Google Account Help: Join or leave a family, checked September 26, 2026.
- Life in the Simulation: Password Managers Compared, for the narrow cases where a shared vault item remains necessary.
END OF FIELD GUIDE 066
Keep the question. Test the model.
Choose the narrowest claim the evidence can carry, then leave room for revision.