macOS login keychain unlock failure after Edge/MSAL com.microsoft.identity.universalstorage oversized metadata warnings

[sam-fakhreddine]

Bug Report: Edge/MSAL keychain write preceded login keychain password failure

Short Title

Microsoft Edge/MSAL write to com.microsoft.identity.universalstorage preceded macOS login keychain no longer unlocking with the user's password

Products

• Microsoft Edge for macOS: 148.0.3967.54
• macOS: 26.4.1, build 25E253
• Architecture: arm64

Date/Time Observed

Initial incident: 2026-05-09 around 11:55 AM MDT.

Same-day recurrence/user report: 2026-05-09 around 21:38 MDT. A follow-up unified-log check at that time showed the same keychain unlock failure class at 21:12 MDT and additional atomic login.keychain-db writes afterward.

Fresh follow-up evidence: 2026-05-10 01:54-07:54 MDT. A targeted six-hour unified-log check showed no new Microsoft identity oversized-metadata warnings, but did show continued login.keychain-db atomic replacement writes plus fresh dp_login/iCloud keychain unlock failures.

Impact

After this event, the user's normal password no longer unlocked the macOS login keychain. The practical recovery was to recreate the login keychain, causing stored keychain material to be lost or re-created and disrupting normal credential access.

Expected Behavior

A Microsoft Edge/MSAL identity token cache write should not leave the macOS login keychain in a state where the user's password no longer unlocks it. If a keychain item has oversized metadata or invalid attributes, the write should fail safely without replacing or damaging the login keychain.

Actual Behavior

System logs show secd warning that a keychain item's metadata exceeded a reasonable size for the Microsoft identity universal storage group. Immediately after that, Microsoft Edge committed a temporary login.keychain-db.sb-* file over the user's login.keychain-db. After the incident, the user's password no longer worked for the login keychain and the keychain had to be recreated.

The issue appears to have recurred later the same day. After the user reported that it "just did it again" at about 21:38 MDT, a local unified-log search showed iCloud keychain unlock failures and a dp_login indirect passphrase lookup error at 21:12 MDT, followed by additional atomic writes to login.keychain-db.

A next-morning six-hour follow-up did not show new Microsoft identity oversized-metadata warnings, but did show that the login keychain remained in an abnormal state: repeated dp_login fallback/failure paths, repeated iCloud keychain unlock failures, and additional atomic login.keychain-db replacements.

Sanitized Log Evidence

2026-05-09 11:54:51.714460-0600 <HOST> secd[799]: [com.apple.securityd:SecWarning] SecDbKeychainItemV7: item's metadata exceeds reasonable size (2959 bytes) (UBF8T346G9.com.microsoft.identity.universalstorage)

2026-05-09 11:54:51.720768-0600 <HOST> Microsoft Edge[1296]: (Security) [com.apple.securityd:atomicfile] 0x104086d3900 committed <HOME>/Library/Keychains/login.keychain-db.sb-3df5c665-bcrVIg to <HOME>/Library/Keychains/login.keychain-db

2026-05-09 11:55:26.429886-0600 <HOST> security[13723]: (Security) [com.apple.securityd:atomicfile] 0xabb00cc00 committed <HOME>/Library/Keychains/login.keychain-db.sb-3df5c665-8T9UnQ to <HOME>/Library/Keychains/login.keychain-db

Post-Incident Evidence That Keychain Unlock State Broke

After the initial Edge/MSAL keychain write, the unified log shows repeated dp_login passphrase fallback attempts and later an explicit iCloud keychain unlock failure followed by a rekey/passphrase change flow:

2026-05-09 12:09:03.226366-0600 <HOST> security[38996]: (Security) [com.apple.securityd:dp_login] indirect passphrase issue, attempting to unlock with password

2026-05-09 12:09:15.361926-0600 <HOST> security[39593]: (Security) [com.apple.securityd:dp_login] indirect passphrase issue, attempting to unlock with password

2026-05-09 12:09:36.641786-0600 <HOST> security[40117]: (Security) [com.apple.securityd:dp_login] indirect passphrase issue, attempting to unlock with password

2026-05-09 14:43:50.846360-0600 <HOST> security[96409]: (Security) Created Activity ID: <ACTIVITY_ID>, Description: SecKeychainUnlock

2026-05-09 14:43:50.873369-0600 <HOST> securityd[399]: Failed to unlock iCloud keychain for uid <UID>

2026-05-09 14:43:50.874120-0600 <HOST> security[96409]: (Security) [com.apple.securityd:dp_login] indirect passphrase issue, attempting to unlock with password

2026-05-09 14:43:50.899207-0600 <HOST> securityd[399]: Failed to unlock iCloud keychain for uid <UID>

2026-05-09 14:43:50.899889-0600 <HOST> security[96409]: (Security) [com.apple.securityd:dp_login] need to rekey, changing to indirect passphrase

2026-05-09 14:43:50.899932-0600 <HOST> securityd[399]: [com.apple.securityd:dp_login] changing passphrase with handle <HANDLE>

2026-05-09 14:43:50.901713-0600 <HOST> security[96409]: (Security) [com.apple.securityd:atomicfile] <POINTER> committed <HOME>/Library/Keychains/login.keychain-db.sb-3df5c665-aiuWPg to <HOME>/Library/Keychains/login.keychain-db

2026-05-09 14:43:50.901978-0600 <HOST> secd[91989]: [com.apple.securityd:dp_login] secAssociateIndirectUnlockKey <INDIRECT_KEY> <HANDLE>

Between 12:24 and 14:06, the same Microsoft identity keychain item continued to trigger oversized metadata warnings:

2026-05-09 12:24:05.470523-0600 <HOST> secd[799]: [com.apple.securityd:SecWarning] SecDbKeychainItemV7: item's metadata exceeds reasonable size (2844 bytes) (UBF8T346G9.com.microsoft.identity.universalstorage)

2026-05-09 12:54:51.821649-0600 <HOST> secd[799]: [com.apple.securityd:SecWarning] SecDbKeychainItemV7: item's metadata exceeds reasonable size (2959 bytes) (UBF8T346G9.com.microsoft.identity.universalstorage)

2026-05-09 13:27:29.456587-0600 <HOST> secd[799]: [com.apple.securityd:SecWarning] SecDbKeychainItemV7: item's metadata exceeds reasonable size (2843 bytes) (UBF8T346G9.com.microsoft.identity.universalstorage)

2026-05-09 14:06:57.527688-0600 <HOST> secd[799]: [com.apple.securityd:SecWarning] SecDbKeychainItemV7: item's metadata exceeds reasonable size (2738 bytes) (UBF8T346G9.com.microsoft.identity.universalstorage)

Same-Day Recurrence Evidence

After the original report was drafted, the same Microsoft identity keychain item continued to trigger oversized metadata warnings. A later cluster also included Microsoft Edge copy_matching errors for a Microsoft Workplace Join access group:

2026-05-09 17:30:23.235028-0600 <HOST> secd[91989]: [com.apple.securityd:SecWarning] SecDbKeychainItemV7: item's metadata exceeds reasonable size (2959 bytes) (UBF8T346G9.com.microsoft.identity.universalstorage)

2026-05-09 17:30:23.238218-0600 <HOST> secd[91989]: [com.apple.securityd:SecWarning] SecDbKeychainItemV7: item's metadata exceeds reasonable size (2795 bytes) (UBF8T346G9.com.microsoft.identity.universalstorage)

2026-05-09 17:30:23.241985-0600 <HOST> secd[91989]: [com.apple.securityd:SecWarning] SecDbKeychainItemV7: item's metadata exceeds reasonable size (3012 bytes) (UBF8T346G9.com.microsoft.identity.universalstorage)

2026-05-09 17:30:24.053156-0600 <HOST> secd[91989]: [com.apple.securityd:SecError] Microsoft Edge[8842]/1#14 LF=0 copy_matching Error Domain=NSOSStatusErrorDomain Code=-34018 "Client explicitly specifies access group UBF8T346G9.com.microsoft.workplacejoin.v2 but is only entitled for (... UBF8T346G9.com.microsoft.identity.universalstorage ...)"

2026-05-09 18:13:51.278880-0600 <HOST> secd[721]: [com.apple.securityd:SecWarning] SecDbKeychainItemV7: item's metadata exceeds reasonable size (2959 bytes) (UBF8T346G9.com.microsoft.identity.universalstorage)

2026-05-09 18:13:51.282692-0600 <HOST> secd[721]: [com.apple.securityd:SecWarning] SecDbKeychainItemV7: item's metadata exceeds reasonable size (2795 bytes) (UBF8T346G9.com.microsoft.identity.universalstorage)

2026-05-09 18:13:51.297440-0600 <HOST> secd[721]: [com.apple.securityd:SecWarning] SecDbKeychainItemV7: item's metadata exceeds reasonable size (3012 bytes) (UBF8T346G9.com.microsoft.identity.universalstorage)

At approximately 21:38 MDT, after the user reported that the problem had just recurred, a unified-log search over the 21:00-21:38 MDT window showed another keychain unlock failure sequence:

2026-05-09 21:12:05.583678-0600 <HOST> securityd[381]: Failed to unlock iCloud keychain for uid <UID>

2026-05-09 21:12:05.584551-0600 <HOST> security[11127]: (Security) [com.apple.securityd:SecError] dp_login: error looking up indirect passphrase: -25308

2026-05-09 21:12:05.597276-0600 <HOST> securityd[381]: Failed to unlock iCloud keychain for uid <UID>

2026-05-09 21:12:05.599967-0600 <HOST> security[11127]: (Security) [com.apple.securityd:atomicfile] <POINTER> commited <HOME>/Library/Keychains/login.keychain-db.sb-a604a42a-aLyb7z to <HOME>/Library/Keychains/login.keychain-db

2026-05-09 21:30:11.830350-0600 <HOST> security[87695]: (Security) [com.apple.securityd:atomicfile] <POINTER> commited <HOME>/Library/Keychains/login.keychain-db.sb-a604a42a-LjhsTw to <HOME>/Library/Keychains/login.keychain-db

Interpretation: the recurrence is not just an isolated initial failure. The Microsoft identity oversized-metadata warnings continued after the first incident, and a later same-day user-visible recurrence was accompanied by fresh dp_login/iCloud unlock failures and atomic replacement writes to the login keychain database.

Fresh Last-Six-Hour Evidence Captured 2026-05-10

Capture window: 2026-05-10 01:54-07:54 MDT.

Targeted searches for the original Microsoft identity signals returned no new matches in this six-hour window:

SecDbKeychainItemV7 / com.microsoft.identity.universalstorage / com.microsoft.workplacejoin:
  0 matches, excluding the diagnostic log command itself.

Microsoft Edge copy_matching / MSAL / keychain access-group errors:
  0 matches.

However, atomic writes to the login keychain database continued during the same window. These were by the security process, not by Microsoft Edge:

2026-05-10 02:30:16.336058-0600 <HOST> security[65612]: (Security) [com.apple.securityd:atomicfile] <POINTER> commited <HOME>/Library/Keychains/login.keychain-db.sb-a604a42a-2SrhSa to <HOME>/Library/Keychains/login.keychain-db
2026-05-10 03:30:17.188053-0600 <HOST> security[16961]: (Security) [com.apple.securityd:atomicfile] <POINTER> commited <HOME>/Library/Keychains/login.keychain-db.sb-a604a42a-65uZ3l to <HOME>/Library/Keychains/login.keychain-db
2026-05-10 04:30:18.021879-0600 <HOST> security[67325]: (Security) [com.apple.securityd:atomicfile] <POINTER> commited <HOME>/Library/Keychains/login.keychain-db.sb-a604a42a-E0n1F7 to <HOME>/Library/Keychains/login.keychain-db
2026-05-10 05:30:18.866288-0600 <HOST> security[19386]: (Security) [com.apple.securityd:atomicfile] <POINTER> commited <HOME>/Library/Keychains/login.keychain-db.sb-a604a42a-tcUrT8 to <HOME>/Library/Keychains/login.keychain-db
2026-05-10 06:30:19.739891-0600 <HOST> security[99859]: (Security) [com.apple.securityd:atomicfile] <POINTER> commited <HOME>/Library/Keychains/login.keychain-db.sb-a604a42a-3ftKCH to <HOME>/Library/Keychains/login.keychain-db
2026-05-10 07:30:20.668438-0600 <HOST> security[1165]: (Security) [com.apple.securityd:atomicfile] <POINTER> commited <HOME>/Library/Keychains/login.keychain-db.sb-a604a42a-wHDyQt to <HOME>/Library/Keychains/login.keychain-db
2026-05-10 07:50:40.626985-0600 <HOST> security[25013]: (Security) [com.apple.securityd:atomicfile] <POINTER> commited <HOME>/Library/Keychains/login.keychain-db.sb-a604a42a-N7PTGR to <HOME>/Library/Keychains/login.keychain-db

A 06:02 MDT sequence showed dp_login failing cached-value unlock, password unlock, and derived-entropy handle unlock:

2026-05-10 06:02:17.431855-0600 <HOST> security[45660]: (Security) [com.apple.securityd:dp_login] indirect passphrase issue, attempting to unlock with password
2026-05-10 06:02:17.433743-0600 <HOST> security[45660]: (Security) [com.apple.securityd:dp_login] unlocking with password failed, hopefully there's recourse
2026-05-10 06:02:17.436768-0600 <HOST> security[45660]: (Security) [com.apple.securityd:dp_login] failed to unlock with handle <HANDLE>
2026-05-10 06:02:17.437018-0600 <HOST> security[45660]: (Security) [com.apple.securityd:security_exception] CSSM Exception: -2147413984 CSSMERR_DL_OPERATION_AUTH_DENIED

A later 07:50 MDT sequence showed repeated iCloud keychain unlock failures, dp_login fallback from cached value to password/derived entropy, an indirect unlock key update, and then another atomic login.keychain-db replacement:

2026-05-10 07:50:36.174795-0600 <HOST> securityd[381]: Failed to unlock iCloud keychain for uid <UID>
2026-05-10 07:50:36.184873-0600 <HOST> security[20642]: (Security) [com.apple.securityd:dp_login] indirect passphrase issue, attempting to unlock with password
2026-05-10 07:50:36.186265-0600 <HOST> security[20642]: (Security) [com.apple.securityd:dp_login] unlocking with password failed, hopefully there's recourse
2026-05-10 07:50:36.213509-0600 <HOST> security[20642]: (Security) [com.apple.securityd:dp_login] successfully unlocked with handle <HANDLE>
2026-05-10 07:50:36.217482-0600 <HOST> secd[721]: [com.apple.securityd:dp_login] secAssociateIndirectUnlockKey item exists, updating
2026-05-10 07:50:38.568173-0600 <HOST> securityd[381]: Failed to unlock iCloud keychain for uid <UID>
2026-05-10 07:50:38.596143-0600 <HOST> securityd[381]: Failed to unlock iCloud keychain for uid <UID>
2026-05-10 07:50:38.871305-0600 <HOST> securityd[381]: Failed to unlock iCloud keychain for uid <UID>
2026-05-10 07:50:39.158997-0600 <HOST> securityd[381]: Failed to unlock iCloud keychain for uid <UID>
2026-05-10 07:50:40.626985-0600 <HOST> security[25013]: (Security) [com.apple.securityd:atomicfile] <POINTER> commited <HOME>/Library/Keychains/login.keychain-db.sb-a604a42a-N7PTGR to <HOME>/Library/Keychains/login.keychain-db

A filesystem check also found one retained temporary keychain database file:

<HOME>/Library/Keychains/login.keychain-db.sb-c4af5ff4-U9orFI

Interpretation: this later window does not show the original Edge/MSAL oversized-metadata warning recurring. It does show that, after the initial Microsoft identity anomaly and same-day recurrence, the machine continued to exhibit abnormal login keychain unlock behavior: dp_login fallback/failure paths, repeated iCloud keychain unlock failures, and recurring atomic replacement writes to login.keychain-db.

One-Week Baseline Check

To reduce the chance that a normal Edge keychain write is being mistaken for the root cause, a seven-day unified-log search was run for the window 2026-05-02 11:55:00 through 2026-05-09 11:55:00.

Summary of matching signatures in that window:

Edge atomic commits to login.keychain-db from login.keychain-db.sb-*:
  17 matches, all on 2026-05-09.
  First: 2026-05-09 08:28:14
  Last:  2026-05-09 11:54:51

Oversized Microsoft identity metadata warnings for UBF8T346G9.com.microsoft.identity.universalstorage:
  16 matches, all on 2026-05-09.
  First: 2026-05-09 08:54:51
  Last:  2026-05-09 11:54:51

Pre-11:55 keychain passphrase failure/rekey signatures:
  0 matches in the seven-day baseline window.

Interpretation: an Edge atomic commit to login.keychain-db by itself may be a weak signal because it can occur as part of normal keychain writes. The stronger anomaly is the cluster of oversized Microsoft identity metadata warnings beginning at 08:54 on 2026-05-09, followed later by dp_login passphrase fallback, iCloud keychain unlock failures, and rekey/passphrase-change activity.

Related Public Reports and Documentation

A web search did not find a public report with the exact same full chain: Edge/MSAL com.microsoft.identity.universalstorage oversized metadata warnings, Edge-associated login.keychain-db atomic replacement, and the login keychain no longer accepting the user's password. However, several public reports and docs align with parts of the observed failure:

• Microsoft Edge Insider community thread, 2020: users reported Edge for macOS showing keychain errors, sync getting stuck, and Edge repeatedly creating login.keychain-db.sb-* files under ~/Library/Keychains, with one user reporting the folder growing from under 10 MB to over 1 GB. Reference: https://techcommunity.microsoft.com/discussions/edgeinsiderdiscussions/a-keychain-cannot-be-found-to-store-microsoft-edge/1350265
• Microsoft MSAL documentation: MSAL for iOS/macOS caches tokens in the keychain; on macOS the default keychain access group is com.microsoft.identity.universalstorage; -34018 normally indicates a keychain access-group/entitlement mismatch. Reference: https://learn.microsoft.com/entra/msal/objc/howto-v2-keychain-objc
• MSAL for Objective-C GitHub releases: recent hotfix notes mention fixing a "legacy keychain on macOS" issue. The release note is too terse to establish the same bug, but it is relevant to triage. Reference: https://github.com/AzureAD/microsoft-authentication-library-for-objc/releases
• Apple Community reports: multiple users reported large numbers of login.keychain-db.sb-* files or daily growth in ~/Library/Keychains; one report says resetting the default keychain solved the file growth. References: https://discussions.apple.com/thread/254606051 and https://discussions.apple.com/thread/254696705
• Microsoft Q&A reports: recent Microsoft app sign-in loops on macOS are commonly routed to clearing Microsoft identity caches and folders, including UBF8T346G9.com.microsoft.identity.universalstorage, com.microsoft.Edge, OneAuth, ADAL/MSAL, and Workplace Join-related keychain material. References: https://learn.microsoft.com/answers/questions/5806095/windows-app-sign-in-pop-up-on-my-mac and https://learn.microsoft.com/answers/questions/5770088/como-puedo-eliminar-las-cuentas-laborales-mac
• Independent keychain debugging write-up: SecDbKeychainItemV7 "reasonable size" warnings in secd logs have been used to identify problematic keychain items, though that write-up was about iCloud/SOS keychain data rather than Microsoft Edge/MSAL. Reference: https://aldur.blog/articles/2024/05/22/secd

Interpretation: the public record supports that Edge/MSAL and broader Microsoft identity components use the implicated macOS keychain access group, that Edge has previously been associated with repeated login.keychain-db.sb-* creation, that Microsoft identity caches can become stale or inconsistent on macOS, and that macOS keychain file storms sometimes require a default-keychain reset. The exact observed 2026 failure chain still appears under-documented publicly and should be treated as a concrete new/recurrent repro for Microsoft and Apple triage.

Known Mitigation and Recovery Status

No public source found during triage describes a true repair path for the exact observed failure chain. Current public guidance is mostly containment and reset-based:

• Apple documents that if the login keychain password no longer matches the user's login password, the user should try the previous login password. If that does not unlock the keychain, resetting the default keychain creates a new blank keychain and deletes saved passwords in the old default keychain. Apple explicitly states that if the old password cannot be provided, the old keychain's information cannot be accessed. Reference: https://support.apple.com/guide/keychain-access/if-you-need-to-update-your-keychain-password-kyca2429/mac
• Apple Keychain Access can export some items, such as certificates and keys, but Apple documents that passwords cannot be exported from Keychain Access. Reference: https://support.apple.com/guide/keychain-access/import-and-export-keychain-items-kyca35961/mac
• Apple Time Machine can restore files and older file versions. A practical recovery attempt, before resetting the keychain, is to preserve the current ~/Library/Keychains folder for evidence and try restoring a known-good pre-incident login.keychain-db from Time Machine or another full-system backup. This is a backup restore path, not a guaranteed keychain repair path. Reference: https://support.apple.com/104984
• Microsoft public troubleshooting for Edge/macOS sign-in focuses on account, sync, cached credentials, profile, and Microsoft identity cache cleanup. It does not document a way to repair a damaged macOS login keychain database after this class of failure. Reference: https://learn.microsoft.com/troubleshoot/microsoft-edge/security/troubleshoot-sign-in-issues

Practical containment steps before another recurrence:

• Quit Microsoft Edge and prevent it from reopening automatically until diagnostic capture is complete.
• Preserve a copy of ~/Library/Keychains and a sysdiagnose before resetting or deleting keychain material.
• Use Time Machine or another full-system backup so ~/Library/Keychains/login.keychain-db has recoverable historical versions.
• Move critical credentials out of the macOS login keychain where possible into systems with independent recovery/export paths.
• If Edge must be used, consider temporarily signing out of Edge sync or using a clean browser profile until Microsoft/Apple triage identifies the triggering identity/keychain item.

Interpretation: there appears to be no vendor-documented "undo" once the login keychain cannot be unlocked and no valid old keychain password or known-good backup is available. The reliable recovery path is prevention through backups and containment; the fallback path is reset and re-authentication.

Additional Context

• UBF8T346G9.com.microsoft.identity.universalstorage appears to be Microsoft identity/MSAL shared keychain storage.
• The issue manifested as the login keychain rejecting the user's correct password.
• Recovery required recreating the login keychain.
• No raw keychain database, secrets, tokens, passwords, account email addresses, or username paths are included in this report.

Questions for Triage

• Can Edge/MSAL write a keychain item whose metadata is large enough to trigger SecDbKeychainItemV7: item's metadata exceeds reasonable size?
• Should the write be rejected before a replacement login.keychain-db is committed?
• Is there a known issue in Edge/MSAL token cache handling or macOS secd atomic keychain replacement that can leave the login keychain unlock state broken?

Suggested Microsoft Edge Routing

Submit via Microsoft Edge: Settings and more > Help and feedback > Send feedback, or open edge://feedback.

Suggested category: Microsoft Edge for Mac / Sign-in / Sync / Identity / Keychain.

Attach this sanitized report text and Edge diagnostics if available. Do not attach a raw keychain database unless Microsoft provides a secure upload path and explicitly requests it.

Suggested Apple Routing

Submit via Feedback Assistant.

Suggested area: macOS > Security & Privacy > Keychain / Security framework.

Attach a sysdiagnose through Feedback Assistant. Do not attach a raw keychain database unless Apple explicitly requests it.

[github-actions]

Hello, thank you for your detailed report. You’ve observed that after Microsoft Edge for macOS (using MSAL for identity) attempted to write token cache data to the keychain, there were warnings about oversized metadata in the com.microsoft.identity.universalstorage access group. Shortly after, the macOS login keychain stopped unlocking with the user’s password and had to be recreated, resulting in credential loss.

Let’s summarize your main triage questions:

1. Can Edge/MSAL write a keychain item with metadata large enough to trigger “SecDbKeychainItemV7: item's metadata exceeds reasonable size”?
2. Should such a write be rejected before a new keychain database is committed?
3. Is there any known MSAL or macOS issue that can leave the login keychain unable to be unlocked after such a write?

1. Can MSAL Write an Oversized Keychain Item?

Yes, MSAL for macOS uses the keychain to store tokens and metadata for user accounts, typically in the com.microsoft.identity.universalstorage access group. There is no explicit limit enforced in MSAL Objective-C on the size of metadata when writing to the keychain. If a cached item (tokens, claims, etc.) or its metadata grows unusually large, it may trigger Apple Security's warning:

SecDbKeychainItemV7: item's metadata exceeds reasonable size (2959 bytes) (UBF8T346G9.com.microsoft.identity.universalstorage)

This warning means MSAL (via Edge) wrote an item whose size Apple considers abnormal—but MSAL does not reject writes based on metadata size by default.

Relevant MSAL API

MSAL does not expose direct controls to limit token cache size in its public API. All token, account, and metadata writes go through internal storage via the configured access group.

2. Should MSAL/Edge Reject Such Writes?

From the perspective of MSAL’s public API, there is no documented enforcement to reject keychain writes based on metadata size. The cache, once configured via MSALPublicClientApplicationConfig, automatically uses the shared access group. If Apple’s keychain APIs (SecItemAdd, SecItemUpdate) succeed, the item is accepted; if they fail (because of attribute, entitlement, or size issues), MSAL surfaces the error from the OS. However, as your logs show, the system only warns—not blocks—these oversized writes.

Actionable MSAL APIs

If you need to clear abnormal or oversized cache items, MSAL provides:

• Account removal:

  NSError *error = nil;
  BOOL success = [application removeAccount:account error:&error];
  if (!success) {
      NSLog(@"Account removal failed: %@", error);
  }

  MSALPublicClientApplication removeAccount:error:

• Cache wipe (destructive):
  ⚠️ Warning: Setting MSALSignoutParameters.wipeAccount destroys ALL keychain material for the user in the access group and will sign out EVERY MSAL-integrated app.

  MSALWebviewParameters *webParams = [[MSALWebviewParameters alloc] initWithAuthPresentationViewController:self];
  MSALSignoutParameters *signoutParams = [[MSALSignoutParameters alloc] initWithWebviewParameters:webParams];
  signoutParams.wipeAccount = YES;
  
  [application signoutWithAccount:account
                signoutParameters:signoutParams
                   completionBlock:^(BOOL success, NSError *error) {
      if (!success) {
          NSLog(@"Signout (GDPR wipe) failed: %@", error);
      }
  }];

  MSALSignoutParameters.wipeAccount

This does not address prevention—it’s only for remediation after cache or keychain corruption.

3. Known Issues or Behaviors

There is no documented MSAL API mechanism that prevents the underlying macOS keychain from becoming un-unlockable due to oversized metadata. If a keychain database becomes corrupt, Apple's guidance is to restore from backup or recreate the keychain, as described in Apple support documentation.

MSAL does not provide public APIs for manual keychain repair, backup, or granular control over storage format. The only exposed mechanisms are:

• Cache/account removal
• Destructive global cache wipe (reserved for privileged apps)

Initial Guidance for Edge/MSAL Developers

• Monitor the size of claims and additional metadata passed to MSAL APIs. Avoid passing very large custom claims or extra scopes to MSALInteractiveTokenParameters.
• If abnormal cache size is detected, prompt for sign-out and removal using MSAL APIs above.
• If multiple apps share the cache (via access group), a destructive wipe affects all. Always warn users if wiping.
• Report the incident to both the Microsoft Edge team and Apple Security as the behavior involves the system keychain.

Objective-C Sample: Remediation via Account Removal

To locally remove MSAL cache for an account (non-destructive) and minimize recurrence:

NSError *error = nil;
BOOL success = [application removeAccount:account error:&error];
if (!success) 
{
    NSLog(@"Account removal failed: %@", error);
}
else 
{
    NSLog(@"Account removed from local cache.");
}

To wipe all user keychain material associated with MSAL (destructive, GDPR-level only):

MSALWebviewParameters *webParams = [[MSALWebviewParameters alloc] initWithAuthPresentationViewController:self];
MSALSignoutParameters *signoutParams = [[MSALSignoutParameters alloc] initWithWebviewParameters:webParams];
signoutParams.wipeAccount = YES; // ⚠️ WARNING: This affects ALL APPS sharing the cache

[application signoutWithAccount:account
              signoutParameters:signoutParams
                 completionBlock:^(BOOL success, NSError *error)
{
    if (!success) 
    {
        NSLog(@"Signout (GDPR wipe) failed: %@", error);
    }
    else 
    {
        NSLog(@"Keychain wiped for all MSAL-integrated apps.");
    }
}];

What to Send Next

• MSAL version in Edge: Which MSAL build is Edge using? This helps correlate with known hotfixes.
• Edge and macOS versions: Already provided—thank you.
• List of known extensions/entitlements: Is anything else sharing the Microsoft identity cache group?
• Exact error codes: If MSAL surfaced an error (especially -34018 or MSALErrorBrokerResponseNotReceived), please provide the error object with [error.userInfo description].
• Any Info.plist customizations: Are there custom MSAL/Edge configuration settings, cache locations, or keychain access group modifications?

Full root-cause analysis likely requires Edge and Apple Security logs, plus impacted user context. If you have additional logs or can reproduce with a minimal MSAL setup, please share those for focused triage.

---

References

• MSALSignoutParameters.h — wipeAccount flag
• MSALPublicClientApplication.h — removeAccount:error:
• MSAL API Usage Examples (.clinerules)
• Apple: If you need to update your keychain password
• Apple: Import and export keychain items
• Microsoft Learn: MSAL token cache/keychain handling

If you have additional cache, entitlement, or MSAL version details, please provide them. This will help narrow down the root cause and determine if a fix or workaround is possible.

---

Need further assistance? Comment with PING-COPILOT: <your question> to trigger a follow-up.

Want to disable automated replies on this issue? Comment with STOP-COPILOT.

This comment was generated by an automated assistant to help with initial triage. A maintainer will follow up as needed.