EIN in privacy-first sandboxes
A synthetic EIN keeps a real company's number out of a test environment, but that alone is not enough: this page treats an EIN as a direct identifier of a legal entity and explains why data minimization has to cover the number and the fields around it together, not the number in isolation.
The number alone is fake, but the real name, address or contact sitting next to it is enough to point back to an actual company.
Reusing one fixture across several environments turns a number meant to be disposable into data that can be correlated across different systems' logs.
A pool of just 1 prefix out of 83 makes it easy to tie every row in that batch back to the same campus, cutting the variety a test dataset is supposed to have.
Not like CPF/CNPJ. Basic validation uses length and IRS-valid prefixes.
It is tied to a legal entity, but for sole proprietors it points straight to one individual; treat it as a sensitive identifier even when the formal holder is a company.
Yes, structurally: the generator only checks format (9 digits, a prefix among the 83 valid ones, a non-zero serial), it never queries the IRS, so overlapping with an already-issued number is always possible.
Only if the repository makes clear the value is synthetic and no real field, vendor name, address or contact, sits paired with it in the same row or commit.
Yes: the same fixture in dev, staging and a public demo turns into a value you can correlate across logs, the opposite of what a disposable test value is supposed to be.
Generation happens locally in the browser. Analytics receives only action, status, type and format, never the generated EIN.