Guides & Reference

Documentation

This page covers how to use Physical Security Atlas: searching the database, submitting records, the bulk CSV format, and the rules that govern responsible use.

Getting started

Physical Security Atlas is open to registered users from approved email domains. After you create an account you'll set up two-factor authentication with an authenticator app (Google Authenticator, Microsoft Authenticator, Authy, or 1Password). You'll enter a rotating six-digit code from that app each time you sign in, and you'll be given one-time recovery codes to save in case you lose your device.

Searching the database

Use the search bar to look up exposed access-control credentials. You can search across everything or narrow to a single field: Building, Company, Credential (card number or raw data), Address, or City. Results show the building, company, card brand and type, and location. Select a record to view its full details.

Submitting a record

From My Uploads you can add a single record by hand or import many at once. Each record captures the raw credential as HEX and/or Binary (at least one is required), the card brand and type, whether it was captured with a Flipper, the building name and company, the full address, and coordinates (filled in automatically from the address). For Wiegand-style formats the facility code and card number are derived from the raw data. You can edit or delete records you own at any time.

What gets validated

Submissions are checked before they are stored, so it helps to know the rules:

  • HEX accepts only 0-9 and A-F; Binary accepts only 0 and 1. Spaces, colons and dashes are allowed and stripped automatically.
  • If you select a Wiegand format, the credential must fit it. A 26-bit format cannot hold 35 bits of data, and a mismatch usually means the format label is wrong — which would silently produce the wrong facility code and card number.
  • MIFARE card types expect a UID of 4, 7, or 10 bytes (8, 14, or 20 hex characters), per ISO/IEC 14443. EM4100 expects a 40-bit (10 hex character) tag ID.
  • If you are recording something that is not a card identifier — a cryptographic key, or a full block dump — set Card Type to Other, since those values have different lengths by nature.
  • Latitude and longitude, if supplied, must be real numbers within ±90 and ±180.

Submitting the same credential again at the same location does not create a duplicate: it updates that record’s last reported date and re-confirmation count. The same credential at a different location is kept and highlighted, because cross-site collisions are a finding in their own right.

Bulk CSV import

To import in bulk, upload a CSV whose header row includes these columns:

Hex, Binary, CardBrand, CardType, WiegandFormat, CapturedFromFlipper, BuildingName, CompanyName, LocationAddress, Address2, LocationCity, LocationState, LocationZip, Country, LocationLat, LocationLong

Provide Hex and/or Binary for each row. Coordinates may be left blank. Each row becomes one record attributed to your account.

Limits and handling:

  • Files must be .csv (or .txt) and 5 MB or smaller.
  • A single import may contain up to 5,000 rows. Split larger datasets into several files.
  • Rows that fail validation are skipped rather than aborting the import, and the count is reported back to you.
  • Rows whose credential is already recorded at the same location are skipped as re-confirmations, and that count is reported separately.

How data is sourced

Records are crowdsourced from security researchers, ethical hackers, and students using tools such as a Proxmark, iCopy-XS, Flipper Zero, or ESPKey. Submissions include metadata, location data, and bit-format length. Every submission is validated automatically before it is stored, each record carries a data-confidence signal derived from the credential itself, and signed-in users can record whether they were able to reproduce a credential at the listed site. Records that several people report as not reproducible are flagged for administrator review.

The first upload

The first record in the database is not a real credential in use at the university shown on the map. We chose to display FFFFFFFFFFFF because it is NXP MIFARE Classic’s standard 6-byte factory default cryptographic key (Key A or Key B) — a fitting first entry for a project about credentials that were never secured in the first place.

Because it is a key rather than a card identifier, it is filed under Card Type Other: at six bytes it is not a valid ISO/IEC 14443 UID, and the validation rules above would correctly reject it as one.

Responsible use

Physical Security Atlas is a defensive tool. It exists so that organizations can find and revoke compromised credentials and adopt more secure access-control standards. Only submit data you are authorized to collect, and use what you find here to improve security — never to gain unauthorized access. Misuse of this information may violate the law.

The rules themselves live in one place rather than being restated here, so that there is exactly one authoritative text: the Terms, Code of Ethics & Acceptable Use Policy. That page is the agreement you accept when you create an account, and it also sets out the licence you grant over records you submit. It is versioned and dated, and the version you accepted is recorded against your account.

Reporting

Report suspected misuse, inaccurate records, or other concerns through Support (sign-in required) or by contacting the team.

Questions not answered here? See the About page for the project's background and FAQ.