What the Unified Log records about Touch ID, passwords and the device that woke the machine. macOS 26.6.2 on Apple Silicon.
A colleague asked me last month whether the Unified Log shows how a Mac was unlocked. Fingerprint or password. And if a key was pressed, which one.
The first question has a long answer. The second one I can settle here: you cannot see which key. You can see which device the input came from, and that turns out to carry more weight than it sounds.
Everything below comes from a reference run on my own MacBook Pro on 27 August 2026. Mac16,8, Apple M4 Pro, macOS 26.6.2, build 25G83. One user account, one enrolled fingerprint, FileVault on. Ten Touch ID unlocks, five presentations with a finger that was not enrolled, five password unlocks. No casework data.
Same layout as my earlier work: full log line first, then the parts that need explaining.
The wake looks the same either way
Whether you are about to use a finger or a password, the wake is identical. powerd logs it:
2026-08-27 11:20:36.269380+0200 localhost powerd[352]: [com.apple.powerd:assertions] Process WindowServer.412 TurnedOn UserIsActive "com.apple.iohideventsystem.queue.tickle serviceID:100000c9c service:AppleHIDKeyboardEventDriverV2 product:Apple Internal Keyboard / Trackpad eventType:3" age:00:00:00 id:38654738439 [System: DeclUser kDisp]
Timestamp: the moment the power assertion was created, which is not the moment the key went down. The log does not quantify the gap.
Process: powerd, which manages sleep, wake and power assertions.
Subsystem: com.apple.powerd:assertions.
Event message: WindowServer raised a UserIsActive assertion because a HID event arrived. The reason string is where the value sits. serviceID:100000c9c identifies the input service, service:AppleHIDKeyboardEventDriverV2 names the driver, product:Apple Internal Keyboard / Trackpad names the device. eventType:3 is a numeric class and I have not established what the number means, so I report it as it stands.
I found the same serviceID and product in seven repetitions across three blocks and ten minutes. The field identifies the device, not the individual event.
Four sources turned up in the run:
| service | Device |
|---|---|
AppleHIDKeyboardEventDriverV2 | internal keyboard |
AppleM68Buttons | power button |
AppleMesaShim | Touch ID sensor |
AppleMultitouchDevice | trackpad |
On a Mac16,8 the Touch ID sensor sits inside the power button, so pressing that button also touches the sensor. In the block where I woke the machine three times with the power button, the log holds three tickles from AppleM68Buttons and three from AppleMesaShim. One physical action, two sources.
Why the key is missing
Once the lock screen appears, loginwindow turns on secure event input. Keyboard input becomes invisible to everything except loginwindow itself. What survives is a delivery record, one line per keystroke:
2026-08-27 11:26:52.941493+0200 localhost WindowServer[412]: (BackBoardHIDEventFoundation) [com.apple.BackBoard:EventDelivery] destinations for Keyboard event: (<keyboardFocus; loginwindow.415; token: viewbridge-key-window>)
You can count keystrokes and time them to the microsecond. You cannot read them.
loginwindow also states which methods it will accept, and the message field holds the string shown on screen:
2026-08-27 11:29:28.155000+0200 localhost loginwindow[415]: [com.apple.loginwindow.logging:Standard] -[LWAuthServiceState update] | show textfield:0, message:'Touch ID or Enter Password', passwordRequried:0, spinner:0
The typo in passwordRequried is Apple’s.
Touch ID
Repetition 1, in the order the lines appear:
2026-08-27 11:20:38.078958+0200 localhost kernel[0]: (AppleMesaSEPDriver) message: type:0x18: kAppleBiometricFingerOnEvent (_sensorState:4, _sensorOpen:1)
2026-08-27 11:20:38.516254+0200 localhost kernel[0]: (AppleMesaSEPDriver) performSpecificCommandGated: TouchID button pressed: 12026-08-27 11:20:38.622877+0200 localhost chronod[741]: (ChronoServices) [com.apple.chrono:keybag] Transition: locked -> inBioUnlock2026-08-27 11:20:38.642326+0200 localhost biometrickitd[434]: [com.apple.BiometricKit:Daemon-Mesa] matchResult:timestamp: MATCH 503: 9C26B226-B86B-49B0-AE8D-19F917B0896F
2026-08-27 11:20:38.699553+0200 localhost kernel[0]: (AppleMesaSEPDriver) message: type:0x17: kAppleBiometricFingerOffEvent (_sensorState:5, _sensorOpen:1)AppleMesaSEPDriver is the driver for the Touch ID sensor, called Mesa internally, and it talks to the Secure Enclave. biometrickitd is the daemon that reports biometric results to the rest of the system.
The match result carries the verdict, the user ID 503, and a UUID for the enrolled template that matched. With one enrolled finger the UUID adds nothing. With several it should identify the finger, and I would like to hear from anyone who can confirm that.
The keybag never reaches “unlocked”
ChronoServices tracks the lock state of the keybag. After a fingerprint it moves into a state of its own:
Transition: locked -> inBioUnlock
Transition: inBioUnlock -> lockingAfter a password it goes where you would expect:
Transition: locked -> unlocked
Transition: unlocked -> lockingCounted across the two blocks, locked -> inBioUnlock occurs only in the Touch ID block and locked -> unlocked only in the password block. Neither shows up in the other.
If I had to pick one artifact from this whole run to take into a case, it would be this one. A single line gives you the authentication method, with no chain to reconstruct and no inference to defend. I have not seen it documented anywhere.
Counting needs care. ControlCenter and chronod both write the same transition, roughly 650 microseconds apart, so a raw count comes out double.
Order between subsystems moves around
Three repetitions of the same physical action:
Repetition 1 gives finger-on at .078958, button pressed at .516254, inBioUnlock at .622877.
Repetition 5 gives finger-on at 08.381118, inBioUnlock at 08.730149, button pressed at 08.740621.
Repetition 6 gives finger-on at 23.992832, button pressed at 24.393155, inBioUnlock at 24.496695.
In repetition 5 the keybag transition arrives ten milliseconds ahead of the button press. In the other two it arrives after. Nobody is wrong here. Sub-second order between subsystems records when each process managed to write, not the sequence in which things happened. Build a chain of events on millisecond ordering across subsystems and you are building on sand.
_sensorState in the finger-off line moves around too. I recorded 5 in some repetitions and 4 in others for the same action, so it is no use as an indicator.
A finger that is not enrolled
The finger-on line is identical, character for character:
2026-08-27 11:24:44.762433+0200 localhost kernel[0]: (AppleMesaSEPDriver) message: type:0x18: kAppleBiometricFingerOnEvent (_sensorState:4, _sensorOpen:1)
2026-08-27 11:24:47.789038+0200 localhost kernel[0]: (AppleMesaSEPDriver) message: type:0x17: kAppleBiometricFingerOffEvent (_sensorState:5, _sensorOpen:1)The result shows up in two places:
2026-08-27 11:24:54.258459+0200 localhost biometrickitd[434]: [com.apple.BiometricKit:Daemon-Mesa] matchResult:timestamp: NO-MATCH2026-08-27 11:24:54.259002+0200 localhost coreauthd[631]: (MechTouchId) [com.apple.LocalAuthentication:Server,Interactive,Biometry] MechanismTouchId[108](run) has received no-match from <private> (lockout state:1)coreauthd is the authentication daemon and MechTouchId is the mechanism that handles fingerprints during a login. The lockout state read 1 in nine of the ten rejections and 4 in one. I have not worked out what drives that, so the range is all I am claiming.
Two things are missing that a successful unlock has. There is no TouchID button pressed line, because I rested the finger without depressing the button. And there is no keybag transition at all. The state machine does not move.
A rejected fingerprint therefore leaves sensor activity in the log and no state change of any kind.
Password
The keystrokes:
2026-08-27 11:29:31.250522+0200 localhost loginwindow[415]: [com.apple.loginwindow.logging:Standard] -[LWDefaultScreenLockUI keyPressed:] | Prewarm SPS2026-08-27 11:29:31.257990+0200 localhost loginwindow[415]: [com.apple.loginwindow.logging:Standard] -[LWDefaultScreenLockUI keyPressed:] | Password view hidden and ! ignore when hiddenThe submission, with a counter that resets every time the screen locks:
2026-08-27 11:29:35.604901+0200 localhost loginwindow[415]: [com.apple.loginwindow.logging:Standard] -[LWDefaultScreenLockUI loginPressed:] | Attempt #: 1
Directory Services checks the credential along two paths, a Secure Enclave credential and a stored hash. Both came back ODNoError, and the account appears as a UUID because the privacy layer hides the name:
2026-08-27 11:29:35.881558+0200 localhost opendirectoryd[380]: (PlistFile) [com.apple.opendirectoryd:auth] Verified password for <private> (F295A618-9A29-4462-A9F5-289BC7F942FB): SEP credential (ODNoError), Shadowhash (ODNoError)
authd is not discreet at all:
2026-08-27 11:29:35.901330+0200 localhost authd[458]: [com.apple.Authorization:authd] UID 0 authenticated as user <user> (UID 503) for right 'system.login.screensaver'2026-08-27 11:29:35.901342+0200 localhost authd[458]: [com.apple.Authorization:authd] Succeeded authorizing right 'system.login.screensaver' by client '/System/Library/CoreServices/loginwindow.app' [415] for authorization created by '/System/Library/CoreServices/loginwindow.app' [415] (302,0) (engine 175)The account name is there in clear text, along with the right that was granted and the binary that asked for it. system.login.screensaver is the right needed to dismiss a locked screen. The engine number ran 171, 175, 179 and 181 across four consecutive unlocks, so it counts authorisation sessions rather than unlocks.
Then the keybag, and the verdict in plain English:
2026-08-27 11:29:35.919501+0200 localhost ControlCenter[670]: (ChronoServices) [com.apple.chrono:keybag] Transition: locked -> unlocked2026-08-27 11:29:35.942199+0200 localhost loginwindow[415]: [com.apple.loginwindow.logging:Standard] -[LWDefaultScreenLockUI authSuccess] | enter. password is CORRECTA wrong password
One repetition failed on the first try. Three processes report it at three levels, and then the counter moves on:
2026-08-27 11:28:51.002252+0200 localhost opendirectoryd[380]: [com.apple.opendirectoryd:session] ODRecordVerifyPassword failed with result ODErrorCredentialsInvalid2026-08-27 11:28:52.870956+0200 localhost authorizationhost[21822]: [com.apple.Authorization:AuthorizationHost] pam_authenticate failed: 92026-08-27 11:28:52.875966+0200 localhost loginwindow[415]: [com.apple.loginwindow.logging:Standard] -[LWDefaultScreenLockUI authFailWithMessage:] | enter. INCORRECT2026-08-27 11:28:57.630566+0200 localhost loginwindow[415]: [com.apple.loginwindow.logging:Standard] -[LWDefaultScreenLockUI loginPressed:] | Attempt #: 2Failed attempts and their order, without inference.
Locking
This one attributes a lock to a specific physical action:
2026-08-27 11:29:04.643883+0200 localhost kernel[0]: (AppleM68Buttons) dispatchEventExt keyboard:12 64 1 time = 189054889202026-08-27 11:29:04.800270+0200 localhost kernel[0]: (AppleM68Buttons) dispatchEventExt keyboard:12 64 0 time = 189092422172026-08-27 11:29:04.957264+0200 localhost loginwindow[415]: [com.apple.loginwindow.logging:Standard] -[LWScreenLock lockScreenImmediateFromTouchIDPress] | Enter2026-08-27 11:29:04.961194+0200 localhost chronod[741]: (ChronoServices) [com.apple.chrono:keybag] Transition: unlocked -> lockingThe trailing 1 is the press and the 0 the release, 156 milliseconds apart. The time value is a monotonic tick count and not wall-clock. lockScreenImmediateFromTouchIDPress puts the lock down to a press on the Touch ID button, not a timeout and not a menu command.
What the user sees
2026-08-27 11:20:39.147043+0200 localhost NotificationCenter[758]: [com.apple.unc:application] update lockscreenMode: unlocked, from: locked-login2026-08-27 11:20:39.147065+0200 localhost NotificationCenter[758]: [com.apple.unc:display] Lockscreen mode changed to unlockedThese two arrive together and are the closest thing in the log to “the desktop appeared”. The from: field names the state it came out of.
The three scenarios side by side
| Touch ID accepted | Touch ID rejected | Password accepted | |
|---|---|---|---|
| Wake source | AppleHIDKeyboardEventDriverV2 | same | same |
kAppleBiometricFingerOnEvent | yes | yes, identical | no |
TouchID button pressed: 1 | yes | not when resting only | no |
matchResult:timestamp: | MATCH 503: <uuid> | NO-MATCH | absent |
MechanismTouchId ... has received | finger-on, finger-off | finger-on, finger-off, no-match | absent |
| Keybag transition | locked -> inBioUnlock | none | locked -> unlocked |
Attempt #: | absent | absent | present, counts up |
Verified password | absent | absent | present |
authenticated as user | absent | absent | present, name in clear |
| Lock transition afterwards | inBioUnlock -> locking | not applicable | unlocked -> locking |
Two rows carry the weight. The keybag transition gives you the method in one line. The authd line gives you the account name in clear text, which the biometric path never does.
Search terms that work
These separate the scenarios cleanly:
chrono:keybag] Transition:
matchResult:timestamp:
has received no-match
queue.tickle serviceID:
Attempt #:
for right 'system.login.screensaver'
lockScreenImmediateFromTouchIDPress
has received no-match has a property that makes it unusually safe. Across the whole run coreauthd writes has received finger-on, has received finger-off and has received no-match, and never has received match. Successful matches are reported elsewhere, in BKMatchOperation. So the phrase has no positive counterpart to confuse it with.
Three terms that will mislead you:
kAppleBiometricFingerOnEvent is identical for an enrolled and a non-enrolled finger. It tells you the sensor was touched and nothing more.
Failed matches Failed SecureToken authentication, which appears immediately before every successful authentication in this run. It records a fallback between credential paths.
MATCH also matches NO-MATCH. Use grep -w or the full matchResult:timestamp: MATCH string.
And read whole lines. Verified password comes with a result in brackets, and that result can be ODErrorCredentialsInvalid. The verb says verified; the value says rejected.
Scope and limits
One machine, one build, one account, one enrolled finger. The counts come from ten Touch ID unlocks, five non-enrolled presentations and five password unlocks, all on 27 August 2026.
Where I read only some repetitions line by line rather than all of them, I have said so. The 437 millisecond gap between finger contact and button press comes from repetition 1; repetitions 5 and 6 gave different figures and a different order.
Extraction was:
log show --archive <path> --style syslog --info --debug --start "..." --end "..."
Both --info and --debug are required. Leave them out and log show drops the levels that carry nearly everything above. That is a discrepancy in its own right and I will come back to it.
If you reproduce any of this on a different Mac, a different build, or a machine with several accounts or several enrolled fingers, I would like to hear about it. The inBioUnlock state and the template UUID in matchResult are the two I am most curious about.
© 2026 Tim Korver — Thesis Friday. Licensed under CC BY-NC-ND 4.0. Method: Anchored Log Reconstruction (ALR). Commercial or training use requires written permission. See Copyright and Use.