Is an Authentication File PII? What New York Law Actually Says

If a system authentication file contains only a person’s name and email address, is that PII? Under New York law, the short answer is no, not on its own. But the reasoning behind that answer is worth walking through, because it’s easy to get wrong, and because a small addition to that file changes the answer entirely.

Name and Email Alone

Under the general definition in GBL § 899-aa, “personal information” is any information that can be used to identify a natural person because of a name, number, personal mark, or other identifier. Name and email clearly qualify as personal information in that broad sense.

But personal information alone doesn’t trigger New York’s breach notification law. What triggers it is the narrower category of “private information,” and a bare name-plus-email combination doesn’t meet that bar. Nothing in the statute’s enumerated list treats an email address by itself, or name plus email by itself, as private information. So an authentication file with just those two fields is PII in the general sense, but not “private information” for purposes of New York’s breach notification duty.

Where It Changes: The Online Credentials Prong

New York’s statute defines “private information” as two separate, independent categories. The first requires a name paired with an element like a Social Security number or financial account number. The second does not involve a name at all.

The statutory text of GBL § 899-aa(1)(b)(ii) defines the second category as: a user name or e-mail address in combination with a password or security question and answer that would permit access to an online account.

That wording stands on its own, separate from the name-based definition in (b)(i). So the trigger isn’t “name plus email plus password.” It’s username or email address, paired with a password or security question and answer. A name doesn’t need to be present at all for this category to apply.

New York is one of a growing number of states, including California, Florida, Illinois, Alabama, Nebraska, Nevada, Rhode Island, South Dakota, Vermont, and Wyoming, that have added a similar online-credentials category to their breach statutes.

This means an authentication file containing an email address and a password (or a security question and answer) crosses into “private information” territory under New York law, whether or not a name is also present, and even without a Social Security number, driver’s license number, or financial account number anywhere in the file.

This is a meaningful departure from the classic breach-law model, which was built around financial and government-issued identifiers tied to a name. Authentication files are exactly the kind of record this newer category was written for.

Encryption and Hashing Complicate the Picture

New York’s statute only treats private information as compromised if the data element, or the personal information paired with it, was unencrypted, or encrypted with a key that was also accessed or acquired. If the password field in the authentication file is properly hashed and salted rather than stored in plaintext, and the hash algorithm and salt weren’t also compromised in a way that makes the password recoverable, the practical risk picture (and the encryption-related defenses available to the business) looks very different than a plaintext password dump.

This is a fact-specific determination, not a bright-line rule, and it’s exactly the kind of question that benefits from involving someone who can assess the cryptographic details of the incident, not just the legal text.

What the Notice Has to Say

New York’s statute has a specific requirement for credential breaches. If the breached information includes an email address combined with a password or security question and answer, the business generally cannot rely on emailing that same compromised address as its method of notice. Instead, when substitute notice is used, the law requires a conspicuous online notice delivered to the consumer when they’re logged into the affected account, rather than a message sent to the very inbox that may no longer be secure.

Federal Overlays Still Apply

Businesses that already comply with breach notice obligations under the Gramm-Leach-Bliley Act, HIPAA/HITECH, or 23 NYCRR Part 500 (the New York Department of Financial Services cybersecurity regulation) are generally not required to send a second, duplicate notice to affected New Yorkers under GBL § 899-aa, though notice to the state attorney general, the Department of State, and State Police is still required. For a paralegal reviewing an incident involving a financial services company or a healthcare-adjacent business, checking which sector-specific framework already governs the notice is a necessary first step before assuming § 899-aa applies in full.

Practical Checklist for Reviewing an Authentication File

When an authentication file turns up in discovery or in incident response, a few questions determine whether it’s “private information” under New York law:

  • Does the file pair a username or email address with a password, or a security question and answer?
  • Was that password or credential field encrypted, hashed, or stored in plaintext?
  • If encrypted or hashed, is there any indication the key, salt, or hashing method was also compromised?
  • Does a federal or sector-specific framework (GLBA, HIPAA, DFS Part 500) already govern notice for this business?
  • Does the file also contain a name paired with a Social Security number, driver’s license number, financial account number, or biometric or medical data that would independently trigger the statute?

Key Takeaway

Name and email address alone, in an authentication file or anywhere else, is PII in the general sense but not “private information” under New York’s breach notification statute. Separately, a username or email address paired with a password or security question and answer is “private information” on its own under GBL § 899-aa(1)(b)(ii), with or without a name attached, and regardless of whether a Social Security number or account number ever enters the picture. For anyone reviewing authentication files, incident logs, or system credentials in a legal context, checking exactly which fields are present, and their encryption status, is what actually determines the outcome.

This post is for general informational purposes and does not constitute legal advice.

References