The TCC access Table Across macOS Versions

TL;DR. The access table in TCC.db has three broad layouts. Mojave and Catalina: allowed (0/1) and prompt_count. Big Sur (11) and later: auth_value, auth_reason and auth_version replace them, and indirect_object_identifier becomes TEXT NOT NULL DEFAULT 'UNUSED'. Sonoma (14) and later: pid, pid_version, boot_uuid and last_reminded are added. Run .schema access on every copy before querying. TCC Parser reads column names from the schema of each file, so the same view works across releases.

Why the schema matters

Queries and parsers break silently on the wrong layout. A script written for Big Sur that selects auth_value fails on a Catalina database; one written for Catalina that filters on allowed = 1 finds nothing on Sonoma. Plaso's macostcc plugin, for example, requires the pre-Big Sur allowed and prompt_count columns, so it targets Mojave and Catalina databases. Velociraptor's MacOS.System.TCC was written against Big Sur. Check first:

sqlite3 TCC.db '.tables'
sqlite3 TCC.db '.schema access'

Mojave and Catalina (10.14, 10.15)

As documented by Plaso's macostcc plugin, the access table has:

The primary key is (service, client, client_type, indirect_object_identifier). That key explains an important behaviour: there is one row per client, service and target, and a new decision replaces the old row rather than adding a new one. The database keeps the current state, not a history.

Big Sur (11) and later

Big Sur replaced allowed and prompt_count with three columns:

indirect_object_identifier became TEXT NOT NULL DEFAULT 'UNUSED', so rows without a target now carry the literal string UNUSED instead of a null. Filter on it when you look for Automation targets.

auth_reason

Apple does not document these values. The mapping below is community-documented and widely used; read it as a hypothesis and confirm on a test Mac of the same version, or against the com.apple.TCC entries in the unified log, before putting it in a report.

The useful distinction in most cases is between user-driven reasons (2, 3), policy-driven ones (5, 6, 7) and system ones (4, 11, 12). Glossary: auth_value, auth_reason.

Sonoma (14) and later

Sonoma added four columns:

The names suggest the process and boot session involved in the decision, but their exact semantics are not publicly documented. boot_uuid is still handy: it lets you group rows by boot session and compare with other artifacts that record a boot UUID. last_reminded is a second timestamp to put on the timeline; in TCC Parser you can switch the time field between Last modified, Last reminded and Expired at.

Newer releases

We know of no public documentation of access schema changes after Sonoma, including macOS 26 Tahoe. That is exactly why TCC Parser is schema-driven: it reads the column list from each file and decodes the columns it recognizes, instead of assuming a fixed layout per release. If you see a column this article does not mention, check it on a test system before interpreting it.

The other tables

The access table gets all the attention, but the database holds more. In the Mojave/Catalina schema documented by Plaso:

List the tables on your own copy with .tables: later releases may differ. The expired table deserves a look in every case, because it keeps clients that no longer appear in access. Its expired_at is Unix seconds, like last_modified. TCC Parser links policy_id to the policies table and to MDMOverrides.plist, and shows REG.db and any other SQLite file found in the com.apple.TCC folder as raw tables.

One query per layout

Mojave and Catalina:

SELECT service, client, client_type, allowed, prompt_count,
       datetime(last_modified, 'unixepoch') AS changed_utc
FROM access ORDER BY last_modified DESC;

Big Sur and later (add last_reminded on Sonoma and later):

SELECT service, client, client_type, auth_value, auth_reason,
       NULLIF(indirect_object_identifier, 'UNUSED') AS target,
       datetime(last_modified, 'unixepoch') AS changed_utc
FROM access ORDER BY last_modified DESC;

Both return blobs (csreq, indirect_object_code_identity) as raw bytes; decoding them is covered in decoding csreq code requirements.

Timestamps

All timestamps in TCC.db are Unix epoch seconds, UTC: last_modified, last_reminded and expired.expired_at. They are not Mac absolute time, which many other Apple databases use. last_modified is the last write to the row: a prompt answered, a toggle flipped, a policy applied. It is not the first grant.

FAQ

Which macOS version replaced allowed with auth_value in TCC.db?

macOS 11 Big Sur. Mojave and Catalina databases have allowed and prompt_count columns; Big Sur and later have auth_value, auth_reason and auth_version instead.

What columns did Sonoma add to the access table?

macOS 14 Sonoma added pid, pid_version, boot_uuid and last_reminded. last_reminded is Unix epoch seconds, like last_modified.

Are the auth_reason values documented by Apple?

No. The commonly used mapping (1 error, 2 user consent, 3 user set, 4 system set, 5 service policy, 6 MDM policy, 7 override policy, 8 missing usage string, 9 prompt timeout, 10 preflight unknown, 11 entitled, 12 app type policy) comes from community research. Confirm on a test system before relying on it.

Why does my query fail on an older TCC.db?

Because the column you selected does not exist in that schema. Run .schema access first and write the query for the columns that are actually there.

Related articles

• TCC.db forensics: the investigator's guide
• Decoding csreq code requirements
• Analyze TCC.db in your browser