Secure Token lost mid session: FileVault locked out on T2 MacBook Pro with Flame services

Question

Level 1

4 points

Secure Token lost mid session: FileVault locked out on T2 MacBook Pro with Flame services

Hi all,

I was actively logged into my admin user account on a 2018 Intel-based MacBook Pro (T2 chip, 2TB SSD) when I tried to approve a standard system-level action—it prompted for my password. I entered the same password I use every day to unlock the machine, and for the first time ever, it was rejected. No typos, no system error—just denial.

Then I locked the screen, and when I tried to unlock, I was locked out entirely.

Since that moment, I’ve never been able to re-enter the admin account. I was mid-session, no reboot, no logout. This was a sudden identity rejection event, and I’m now permanently locked out of FileVault on my main internal disk—despite having the correct password.

⚙️ System Details:

MacBook Pro 15” (2018, Intel)
2.9 GHz 6-core Intel Core i9
32 GB DDR4 RAM
2 TB SSD
Radeon Pro Vega 20 4 GB
Touch Bar + Touch ID
T2 Security Chip
macOS 14.1.1 (Sonoma)
FileVault enabled
Admin user account (now locked)
Non-admin user account (still accessible)

🧨 Setup History — Flame & Framestore Services:

This machine was used professionally since 2019 as a Flame workstation (Autodesk Flame). I had:

Internal (Partitioned FV-Secure Internal Drive with Main Admin Account Mentioned in This Post holding 1.5TB space in the entire Macbook System, leaving to the non-admin account another 500GB as no erase action has been taken so far) + external framestore configuration (8TB USB-C external SSD)

Flame-related services: IFFFS, Wiretap, Backburner installed

Framestore indexing and root-level permissions likely persisted, even though Flame hasn't been launched in over a year > A recent Flame related Backburner issue was ignored. I suspect that permissions on a root access level create discrepancies.

The locked admin account was the only one authorized to manage drives and Flame mounts

🚨 Current State:

Admin password rejected at FileVault unlock screen
Password also rejected at TDM unlock prompt
Recovery keys (2) also rejected
Admin account appears in FileVault user list but returns:

“Authentication is disabled”

From the non-admin user session:
Disk Utility shows: “Disk Ownership: Disabled”
The 8TB external drive cannot be mounted (requires admin-level approval)
sudo not permitted (expected from non-admin)

🔍 What I Think Happened:

A macOS update (14.1.1) or system security refresh revoked the Secure Token from my admin account

Possibly triggered by:

Legacy Flame root-level service hooks
Unresolved ACL entries from framestore indexing
T2 Secure Enclave refresh error in-session

This appears to be a case of token-to-decryption disassociation, not user error. The password is correct, but FileVault no longer binds it to a valid decryption identity

🧪 What I'm Trying Next:

Mounting the drive via Target Disk Mode and unlocking it from a second Mac (still fails)
Planning to bring both drives to an Apple Authorized Service Provider
Seeking Secure Token reassignment or FileVault authority restoration

I hold all credentials, device access, purchase receipt, and daily-use Touch ID registration (as further proof of identity)

🧠 What I’m Asking the Community:

Before I escalate and risk data loss, I’d deeply appreciate:

Any similar cases of Secure Token loss or T2 Secure Enclave disassociation mid-session
Advice from those who've resolved similar lockouts caused by Flame-rooted service conflicts
Guidance on whether Apple internal tools (e.g., AST 2, Configurator 2) can rebind FileVault without erasure
Clarity on the role of Touch ID as a behavioral proof of use—even if not directly usable to decrypt FileVault

This system holds high-value data, creative projects, and irreplaceable Apple Notes entries. I was fully authorized and operating minutes before being locked out. If this points to a broader risk in systems using framestore services with Flame, especially in T2-secured Macs, I hope this post can help document the issue—and possibly prevent irreversible lockouts for others.

Thank you in advance to anyone willing to lend technical insight or context.

— Alaz

[Re-Titled by Moderator]

MacBook Pro 15″, macOS 14.1

Posted on Apr 6, 2025 07:57 AM

Reply

Answer 1

alazco Author

Level 1

4 points

Apr 6, 2025 08:03 AM in response to alazco

🔍 Related Cases Where Mid-Session Authorization or Trust Broke

These cases may relate to or help frame what happened in my situation:

1. Secure Token Revocation Mid-Session

Some users allegedly reported cases after macOS updates (especially post-Catalina and onward) where a Secure Token was silently dropped from a primary user account. It typically showed up after reboot, but there are rare cases where a live session stopped recognizing the user’s token, often triggered by a change in system permissions or a failed system integrity re-check.

✅ Relevant to: sudden loss of authorization while logged in

2. TCC or authd Daemon Failure

The Transparency, Consent, and Control (TCC) database and the authd (authorization daemon) govern trust relationships between user credentials and system components. If these daemons crash or return invalid identity assertions, macOS may revoke permission mid-session, even from an authenticated user. This can cause:

System Settings changes to fail
Keychain Access denials
Immediate logout or lockout upon screen wake

✅ Relevant to: being asked for a password in-session, then immediately rejected

3. Flame / Framestore Root Access Conflicts

Autodesk Flame installs services that can alter disk mount behaviors and root-level access—like IFFFS, Wiretap, and Backburner. These daemons may:

Create background processes with root control
Assign modified ACLs or extended attributes to mounted disks
Conflict with macOS updates that tighten security controls (e.g., changes in SIP or APFS permission parsing)

✅ Relevant to: Flame framestore volumes being tied to a single user identity which then fails post-update

4. Touch ID Token Invalidated Post-Sleep or Lock

In rare scenarios, Touch ID tokens cached in the Secure Enclave are invalidated after a timeout, keychain mismatch, or idle lock. If the system then re-prompts for password and fails to resolve the user token binding, even the valid password can be rejected by FileVault or system-level actions.

✅ Relevant to: suddenly being asked for password instead of fingerprint, then getting denied

5. Disk Ownership Lost via Permission Drift or External Volume Conflict

When disk ownership is “disabled”, macOS treats you as a guest, even in an active session. This can happen when:

A new APFS volume was added incorrectly
An external drive introduces conflicting owner UUIDs
Legacy software (like Flame) rebinds system mount behaviors
System startup integrity check mismatches token references

✅ Relevant to: Disk Utility showing “Disk Ownership: Disabled” even when logged in

Reply

Answer 2

alazco Author

Level 1

4 points

Apr 6, 2025 08:32 AM in response to alazco

🔥 Flame Daemon Conflict Before FileVault Lockout — Warning Ignored?

Just a brief note to add to my earlier post on being locked out of my admin account mid-session:

About 2–3 weeks prior to the lockout, I recall Flame (Autodesk) prompting me to report a system issue. I dismissed it at the time since I hadn't used Flame actively for months. But now I suspect that alert may have pointed to a framestore or root-level permissions conflict—possibly with background services like IFFFS or Wiretap.

The machine later revoked Secure Token access mid-session, and now:

FileVault rejects the correct password
Recovery keys fail
Disk ownership is disabled from my non-admin account

This may be worth looking into for other users running legacy Flame setups on macOS 14+. It might have been an early indicator of a deeper token or authorization chain failure.

Would love to hear if anyone else noticed Flame system flags before similar trust issues.

— Alaz

Reply