The Household Attack Surface

The household attack surface is a linkage map, not a secrecy score

A household attack surface is an inventory of identifiers supplied to services, recovery channels that can restore access, and information required in official records.

The framework keeps those channels separate before asking how they may connect. An identifier belongs in the map because a specific system requests it. A recovery channel belongs there because a provider has described a route for regaining or transferring access. An official-record field belongs there because a named authority requires or governs it. A single entry does not prove that the channels identify the same person, reveal a residence, or form a universal household profile.

The four bounded examples in this page show why the separation matters. Bitwarden states that a valid email address is required to complete signup. Bitwarden Emergency Access lets a designated trusted emergency contact request vault access, with the request approved by the account holder or after the specified wait time expires. Massachusetts law addresses a substitute address for a program participant when an agency creates a new public record, subject to the rule's exceptions. Alabama law separately addresses what an Alabama limited liability company must state about its registered office in a certificate of formation.

Those examples are not a count of every household identifier, recovery mechanism, or record system. They are four entries with four evidence boundaries. The useful question is not whether a household has a high or low score. The useful question is which system holds each entry, what function it serves, who or what can act through it, and what the cited source does not establish.

Why boundaries matter when records remain lawful

Massachusetts example: State and local agencies must accept the secretary-designated substitute address when creating a new public record, subject to statutory/administrative need exceptions.

The Massachusetts rule is a bounded example of changing the address used in a record-creation process rather than making every lawful record disappear. It applies to Massachusetts state and local agencies, to a program participant's secretary-designated substitute address, and to the creation of a new public record, with statutory or administrative-need exceptions preserved by the cited source. The example does not establish the rules in another state, the treatment of every existing record, or the coverage of every record system.

That boundary belongs in the inventory beside the address itself. Record the authority as Massachusetts, the mechanism as a substitute address designated by the secretary, the covered act as creating a new public record, and the exceptions as a known limit. Keeping those fields together prevents the shorthand substitute address from becoming an unsupported claim that an address is absent everywhere.

The same discipline applies to any privacy measure that changes where information appears. Name the system affected, the authority or provider that controls it, the action the measure changes, and the records or processes the source leaves outside its scope. Privacy in this framework means a defined boundary around a defined channel. It does not mean secrecy from every lawful process, and it does not convert one jurisdiction's rule into a national result. For the jurisdictional context, see Address Confidentiality Programs by State.

Identifiers and recovery channels are separate linkage surfaces

Bitwarden requires a valid email address to complete signup, while Bitwarden Emergency Access lets a designated trusted emergency contact request vault access under a separate approval-and-wait process.

The Bitwarden signup email and Bitwarden Emergency Access belong on different lines of an exposure inventory. The email is an identifier the provider says is required to complete signup. Emergency Access is a provider-described access path: a designated trusted emergency contact may request vault access, and the request is approved by the account holder or after the specified wait time expires. The cited material does not establish that the emergency contact is a household member, and the signup requirement does not make the email anonymous.

Separating the entries keeps the audit focused on functions instead of labels. For the signup line, record Bitwarden as the system, valid email address as the required identifier, and the provider terms as the source. For the Emergency Access line, record Bitwarden Emergency Access as the mechanism, designated trusted emergency contact as the requesting actor, and account-holder approval or expiry of the specified wait time as the described path. Do not merge the two lines merely because they sit inside the same provider relationship.

This distinction also clarifies the next review step. An identifier review asks what is supplied at enrollment and what purpose the provider gives it. A recovery review asks who or what can initiate a request, which approval or delay governs the request, and what access the provider says may follow. The two reviews can be compared later, but neither one proves a household relationship on its own.

Why a privacy control can create a new linkage surface

Alabama example: An Alabama LLC's certificate of formation must state the street address, including the county, of its registered office in Alabama.

The Alabama requirement belongs in the inventory even when a separate privacy control changes a business's contact point. The cited source establishes what the certificate of formation must state about the registered office. It does not establish that the address is a residence, that the address is searchable or indexed, that it can be reused elsewhere, or that it is connected to a beneficial owner. Those are separate questions that need separate evidence.

A careful map therefore distinguishes the control from the remaining filing field. One line can describe the control and the system it changes. Another line can record Alabama's certificate-of-formation requirement, the Alabama registered office to which it applies, and the statute as its authority. The two lines may be reviewed together, but the existence of one does not supply facts missing from the other.

This is the practical meaning of a new linkage surface in this framework: a control may relocate a contact function while another named system still requires a specific field. The map should show both systems and stop at the source boundary. It should not call the arrangement private, public, hidden, exposed, or effective unless evidence supports the particular label. What makes a business filing a public record addresses the separate public-record question; the Alabama source here establishes only the formation-certificate address requirement.

Build the inventory by system and authority

Build one row per evidence-bound entry, with fields for system, identifier or address, collecting authority, recovery actor, source date, and known limit.

The row is the unit of analysis. It prevents an identifier, recovery path, and official-record requirement from collapsing into a single claim about a person or household. Use the source date attached to the accepted record or cited source; do not substitute the date the inventory happens to be read. When a field is not established by the cited evidence, leave it blank or mark the limit instead of inferring a value.

1. System: name the provider, product, agency, filing instrument, or record-creation process to which the entry belongs.
2. Identifier or address: record only the email, address field, or other item that the cited evidence actually names.
3. Collecting authority: name the provider or government authority responsible for the cited requirement; leave this field blank when the evidence does not establish one.
4. Recovery actor: name only the actor the provider identifies; do not convert a trusted emergency contact into a household member.
5. Source date: preserve the accepted record's capture date or the source's checked date so the entry can be reviewed against the same evidence boundary.
6. Known limit: state what the source does not prove, including jurisdiction, coverage, searchability, reuse, or household relationship when those points remain open.

• Bitwarden signup example — System: Bitwarden; identifier or address: valid email address required to complete signup; collecting authority: Bitwarden; recovery actor: blank; source date: captured October 4, 2026; known limit: the record does not make the email anonymous.
• Bitwarden Emergency Access example — System: Bitwarden Emergency Access; identifier or address: blank; collecting authority: Bitwarden; recovery actor: designated trusted emergency contact; source date: captured October 4, 2026; known limit: the record does not establish a household relationship.
• Massachusetts example — System: creation of a new public record; identifier or address: secretary-designated substitute address; collecting authority: Massachusetts state or local agency; recovery actor: blank; source date: checked September 30, 2026; known limit: statutory or administrative-need exceptions and no nationwide generalization.
• Alabama example — System: Alabama limited-liability-company certificate of formation; identifier or address: street address, including county, of the registered office in Alabama; collecting authority: not established by the cited source; recovery actor: blank; source date: checked October 4, 2026; known limit: no conclusion about residence, searchability, indexing, reuse, or beneficial ownership.

What this framework cannot prove

The four cited examples do not prove universal coverage, public searchability, downstream reuse, or a household relationship.

The boundaries are part of the result, not a footnote. The examples do not establish every identifier, recovery method, public record, or jurisdiction that can affect a household. They also do not show that the same person appears in every channel. A complete-looking diagram must not turn four bounded source records into a universal model of a household.

• Public is not established merely because a government filing or record-creation rule is cited. The evidence must separately establish who can access the resulting record.
• Searchable is not established by the Alabama formation-certificate requirement. The cited Alabama source does not describe a search portal, index, query key, or displayed result.
• Recoverable is specific to the provider-described mechanism. The Bitwarden Emergency Access record does not establish a general rule for other password managers or recovery systems.
• Household-linked is not established by a required signup email, a designated trusted emergency contact, a substitute-address rule, or a registered-office address requirement. None of the four sources proves that relationship.
• Reusable is not established by the cited examples. A separate source would be required before describing an identifier or address as reusable across systems.

Treat each blank field and known limit as a prompt for evidence, not an invitation to complete the pattern. A source-bounded inventory can show that a question remains unanswered without turning that gap into a negative claim. The framework is educational: it organizes what the named sources establish and keeps public, searchable, recoverable, reusable, and household-linked states distinct. It does not provide a privacy score, a vendor verdict, legal advice, or an anonymity guarantee.