VoiceDebrief iOS / sgit-app / secrets / opportunity

The secrets manager: the field and the opportunity

A research brief written for the secrets manager design on 14 November 2026, by a research agent working from public sources. Treat prices as approximate (most come from aggregator sites that disagree), and anything marked (judgement) as opinion. It is input to the design, not a decision: the owner decides, through the questions in the app and on the design page.

Date: 14 November 2026. Prices move often and many figures below come from aggregators; check vendor pages before quoting them. Anything marked (judgement) is my opinion, not a sourced fact.

1. The field, 2025 to 2026

Product	Sync	Sharing	Trust and identity	Passkeys	Pricing shape	Strength	Weakness
1Password	Vendor cloud	Shared vaults, organisation accounts	Vendor account plus Secret Key; the vendor directory supplies members' public keys	Yes; exports through Credential Exchange on iOS	Personal, Families, Teams, Business seats	Polish, Secret Key design	Subscription only, cloud only
Bitwarden	Vendor cloud or self-hosted	Organisations and collections; a free organisation holds 2 people	Vendor account; the server supplies members' keys	Yes; early adopter of iOS 26 export	Free, Premium, Families (6 people, about $3.99 a month), Teams and Enterprise per seat	Open source, cheap	Several malicious-server attacks found in 2026
Apple Passwords	iCloud Keychain	Shared Groups; owner adds members; an item lives in one group	Apple Account	Native	Free	Built in, zero setup	Apple-only; no permissions; people removed may keep what they saw
Proton Pass	Vendor cloud	Shared vaults on paid plans	Proton account	Yes	Free, Plus, Family, Business	Privacy brand, low price	Younger product, fewer team controls
Keeper	Vendor cloud	Shared folders with permissions	Vendor account	Yes	Limited free tier, Family about $3.83 a month, Business	Enterprise compliance	Upselling, add-on pricing
Dashlane	Vendor cloud	Sharing and groups	Vendor account	Yes	Mostly paid; sources disagree on whether a free tier remains	Clean business admin	Malicious-server findings, price
KeePassXC / Strongbox	A file; you choose the sync (Dropbox, iCloud, WebDAV)	Share the file and its password	None: whoever holds the file and password	Strongbox yes; KeePassXC has some	Free / freemium or lifetime	No vendor, open format	Sharing and merge conflicts left to the user
Doppler	SaaS	Projects and environments	Org SSO	n/a	Free tier, then per seat	Developer experience	Proprietary, SaaS only
Infisical	SaaS or self-hosted	Projects, machine identities	Org accounts, machine identities	n/a	MIT core, Pro priced by identity	Open core, self-host	Org-first, needs an admin
HashiCorp Vault	Self-hosted or HCP	Policies	Auth backends, tokens	n/a	BSL 1.1 since 2023; OpenBao is the MPL fork	Power, dynamic secrets	Heavy to run, licence worry
1Password Secrets Automation	Vendor cloud	Service accounts, Connect server	1Password org	n/a	Part of business plans	Same store for people and machines	Tied to a 1Password business account

Common thread: all but KeePass rely on an account with a company for identity, and "end-to-end" sharing means the vendor's server hands you the other person's public key, the weakness the 2026 ETH Zurich study used. (judgement)

Sources: Bitwarden pricing summary, Apple Shared Groups guide, Keeper pricing, Infisical on pricing, Vault licensing, Bitwarden on passkey portability.

2. Recurring pain points

Breaches have a long tail. Vaults stolen from LastPass in 2022 were still being cracked in 2025; TRM Labs traced about $35m in crypto thefts to them, and the UK ICO fined LastPass £1.2m. URLs were stored unencrypted, which told attackers which vaults were worth cracking. (The Hacker News, Infosecurity)
"Zero knowledge" is only as good as the server's honesty. ETH Zurich and USI showed 25 or more attacks against Bitwarden, LastPass and Dashlane under a malicious server, grouped under recovery, key escrow, sharing and legacy crypto. (IACR ePrint 2026/058, The Hacker News)
Family and small-team sharing. Free tiers stop at two people (Bitwarden); Apple's groups have no roles beyond owner and member, and Apple warns that people you remove may keep what they saw. (Apple, TWiT)
Lock-in and passkey portability. Passkeys were stuck in one manager until FIDO's Credential Exchange. Apple shipped it in iOS 26, but CXF is a standard while the CXP transport was still a draft in mid 2026, and desktop support is patchy. (Corbado, analysis)
Trust networks fail open. The 2019 SKS attack flooded two people's PGP certificates with about 150,000 signatures because anyone could sign anyone. (Hansen)
Developers and agents. GitGuardian counted about 28.65 million new secrets in public GitHub commits in 2025, AI-service secrets up 81%, and over 24,000 in MCP config files; more than 60% of secrets found in 2022 still worked in 2025. (Help Net Security, GitGuardian)
Onboarding and recovery are where people give up and where security weakens; recovery is the ETH paper's first category. (judgement)

3. Ten things SGit Vaults could do better

Ranked by value to a team of 5 to 20, weighted by how directly the architecture gives it. (judgement)

A team with no admin and no company account. Value: five people are sharing within ten minutes, with no sign-up, invoice or IT person. Why possible: identity is a key pair and membership is a confirmed link, not a row in a vendor database. Risk: nobody is in charge when someone leaves or loses a phone.
Sharing that a dishonest server cannot redirect. Value: you know the key you seal to belongs to the person you met. Why possible: keys come from cards confirmed in person, never from the server, which shuts out the key-substitution sharing attacks in the ETH study. Risk: people skip the confirmation step if it feels like work.
Secrets for agents, scoped and visible. Value: hand an AI session one API key for one job, not a .env file. Why possible: agents have keys and append lanes, so a secret is a sealed message to that agent alone. Risk: an agent that leaks it still leaks it; you need expiry and rotation reminders.
Signed history of every change. Value: "who changed the router password, and when?" has an answer, and you can roll back. Why possible: signed commits are the storage model, not an audit add-on. Risk: history also keeps old secrets, so rotation must be explained clearly.
No lock-in. Value: leave, self-host or keep several remotes without asking anyone. Why possible: local first, server holds only ciphertext, open format. Risk: "where is my data?" becomes a question users must understand.
Ask for a secret from someone outside the team. Value: a contractor drops the Wi-Fi or AWS key into your inbox; no shared document, no chat log. Why possible: the append lane is write-only, so the sender gets no read access. Risk: spam and floods, so lanes need limits and easy rotation; the sender still needs something that can seal (the app or a small web page), which must be built.
Rotation on a branch. Value: change a production key, test it, then merge, so the team is never half on old and half on new. Why possible: branches and merges are native. Risk: too developer-flavoured for families; hide it there.
Recovery through people you trust. Value: lose every device and get back in with help from three of five confirmed contacts, no vendor reset. Why possible: confirmed contacts and sealed messages already exist; key shares are just more sealed messages. Risk: hard to get right; a mistake here undoes the whole security story.
A breach of the server reveals almost nothing. Value: no LastPass-style list of which sites you use. Why possible: objects are encrypted, including names and URLs. Risk: sizes, timing and who talks to whom still leak; say so plainly.
On-device help. Value: sort an import, spot a key pasted into a note, explain a change in plain words, with nothing sent to a cloud. Why possible: Apple's on-device models only. Risk: small models make mistakes; keep them suggesting, never deciding.

Honest limit: removing a member means new vault keys and changing the secrets they saw.

4. iOS platform facts that constrain it

AutoFill Credential Provider extension. Subclass ASCredentialProviderViewController in an extension and add the com.apple.developer.authentication-services.autofill-credential-provider entitlement to both the extension and the app (Apple). Declare capabilities in the extension's Info.plist under NSExtension > NSExtensionAttributes > ASCredentialProviderExtensionCapabilities: ProvidesPasswords, ProvidesPasskeys, and optionally ProvidesOneTimeCodes and ProvidesTextToInsert (Apple forums).
Passkeys in a third-party provider (iOS 17+). prepareCredentialList(for:requestParameters:) for sign-in, prepareInterface(forPasskeyRegistration:) for creating a passkey, and ASPasskeyCredentialIdentity in ASCredentialIdentityStore for QuickType suggestions. Early iOS 17 had bugs, fixed by 17.4 (Apple), forum). The provider stores the passkey's private key itself.
iOS 18 and later add one-time codes (prepareOneTimeCodeCredentialList), text insertion, and conditional (automatic) passkey upgrade (performWithoutUserInteractionIfPossible(passkeyRegistration:)). The latest SDK also adds save and generate password requests and the report... signals from sites. iOS 26 adds Credential Exchange import and export (ASCredentialExportManager) (Apple, Corbado).
Face ID. LocalAuthentication (LAContext) or a keychain item protected by SecAccessControl with a biometry flag; the app must set NSFaceIDUsageDescription.
Secure Enclave. It holds P-256 keys only and they never leave the device. The signing key could live there per device; RSA-4096 cannot, so it must be wrapped by an enclave key or stored as an ordinary keychain item. (design consequence, my judgement)
iCloud Keychain sync. kSecAttrSynchronizable items cannot use any ...ThisDeviceOnly accessibility value or kSecAttrAccess (Apple, Apple). Syncing keys there makes Apple's account a recovery path.
App Groups and keychain sharing. The extension runs in its own process, so vault files go in a shared App Group container and keys in a shared keychain access group (keychain-access-groups). The extension should read a small index, not a whole vault, as extensions get less memory. (judgement)
Needs the account holder (or an Admin) in the developer portal: an App ID for the extension, the AutoFill Credential Provider capability on both App IDs, the App Group and keychain group registered, and new provisioning profiles. A Mac build needs the same on the macOS side.

5. First-run and team storyboard

One person alone

Welcome: "Your secrets, in vaults only you can open." One button.
Face ID consent; keys generated on the device (show it happening, a few seconds).
Your card: name and a photo you take now. Explain that the photo helps friends know it is you.
First vault created locally; offer to import (Apple Passwords, 1Password, Bitwarden, CSV, Credential Exchange on iOS 26).
Turn on AutoFill: ASSettingsHelper opens the right Settings page.
Optional: add a remote server. Optional: recovery later, when you have contacts.

Two people meeting

"Add someone": both open a QR screen. A scans B.
A sees B's card with B's photo, takes a quick photo of the person in front of them, and compares. "Is this the person in front of you?"
Both phones show the same short safety code (six words or digits). Both say it aloud and tap Confirm. A link exists only when both confirm.
Remote fallback: card sent over a messenger, confirmed by video call with the same code. Mark it "confirmed remotely".

A group of five

One person starts "New team" and shows one QR; others scan it and each card appears in a grid with photos.
Each pair that has not confirmed yet gets a tick to do; the app shows who is still unconfirmed. A shared vault can include only people the creator has confirmed. (judgement: do not let trust pass through others)
Name the team vault, pick members, done; each member's copy of the key is sealed to their key.
Offer recovery: "Choose three of these four to help you get back in."

6. Decisions for the product owner

Is iCloud Keychain allowed to hold keys? Recommend: no for identity and vault keys by default; offer it as an opt-in recovery aid with a clear warning.
How do people recover after losing every device? Recommend: social recovery through confirmed contacts (threshold such as three of five), plus a printed recovery sheet. No vendor reset, ever.
Must every team member confirm every other member? Recommend: the vault creator must have confirmed each member; members need not confirm each other to read, but must to share onward.
Is AutoFill (passwords and passkeys) in version one? Recommend: yes for passwords and passkeys; it is the daily habit that keeps people in the app. Leave one-time codes and text insertion for later.
What does removing a member do? Recommend: re-key the vault automatically, then show a checklist of the secrets that person saw, with "rotate" actions. Never imply removal un-shares the past.