On macOS 26, when a passkey sign-in flow is started in Safari or another WebKit-based browser (for example, DuckDuckGo browser), smart cards become inaccessible as soon as the password manager selection UI is shown, but only if the website offers “Security Key” as one of the passkey storage/authentication options.
At that moment, it appears the system starts polling connected smart cards and does not properly release the transaction/session. As a result, other applications and libraries can no longer communicate with the smart card until the passkey UI is dismissed, and in practice the card may remain unavailable until the passkey sign-in flow is fully completed.
This does not happen in Chrome. This does not happen if the website does not offer the “Security Key” option. This does not happen during passkey registration; the issue affects sign-in only.
From our investigation, Safari/WebKit appears to open communication with connected smart cards and keep the transaction/session active. Because of that: • our own smart card code blocks while waiting for a PC/SC transaction to begin; • the system pcsctest utility also hangs and does not continue until the passkey selection UI is closed; • a minimal sample using TKSmartCard also blocks on beginSession().
This suggests the smart card is locked not only at the PC/SC level, but also at the CryptoTokenKit level.
This issue is critical for us. We are developing a password manager that supports storing keys on a smart card, and due to this behavior we cannot access our card while Safari/WebKit is showing the passkey flow.
Is there any way to stop safari from accessing smartcards? Any terminal commands/settings/workarounds?