A separate app made stored credentials easier to inspect
iOS 18 introduced the standalone Passwords app in 2024. Earlier iPhone versions kept the main saved-password interface in Settings > Passwords. The new app changed where many people find their credentials; it did not invent passwords or passkeys, and it did not make every website support the same sign-in methods.
Use this guide to inspect your own saved credentials on a supported Apple device. Authentication protects access to the app. If a workplace or school manages the account, follow its credential rules. A password entry is sensitive information, so do not share a screenshot of its details while asking someone to identify the right item.
Search for the website, then inspect the account
Open Passwords and authenticate. Search for the service's name or domain, then inspect the matching entries. Check both the website and the username. Two accounts at the same service may be legitimate, and a familiar display name can hide an old email address you no longer use.
For an account created with a Hide My Email alias, the username may be that alias rather than the inbox receiving forwarded mail. Save and use the exact account identifier. The Hide My Email guide explains why those two addresses have different roles.
Distinguish passwords from passkeys
A password is a secret you may need to enter or autofill at the service. A passkey uses a different sign-in mechanism supported by the service and device, commonly confirmed with device authentication. A passkey is not a password you can reveal and type into an arbitrary form. A site can offer both methods or use one during a transition.
If a site offers a passkey, follow its genuine account setup process and confirm how recovery and alternative access work for that service. Do not remove the existing method until you understand the new arrangement and have tested it. Support varies, so a passkey option on one website does not establish that another website accepts it.
| Action | What it changes | What it does not necessarily change |
|---|---|---|
| Edit a saved password entry | The credential stored in your password manager | The website's actual account password |
| Change the password at the website | The service's accepted password | Every old saved entry automatically and correctly |
| Delete a saved entry | Your stored record | The account or its subscription at the service |
| Create a passkey through a supported service | A supported sign-in credential | Every recovery method or other device's readiness |
| Share a credential through supported controls | Access for the selected recipients | The service's rules about account sharing |
Change a password in the right place
Suppose an old password is reused at two services. Open the first service through a trusted route, use its account-security settings and set a strong unique replacement. Let Passwords save or update the entry when the legitimate workflow offers it. Then sign out and back in if appropriate to verify that the stored credential matches what the service accepts.
Merely typing a new value into Passwords does not instruct the website to change its password. Conversely, changing the website password but dismissing every save prompt can leave an obsolete local entry. If sign-in fails afterward, compare the intended account and the saved record without repeatedly resetting unrelated accounts.
Use security warnings as a queue for action
The app can surface concerns such as reused or compromised passwords where supported. Work through important accounts first and make changes at the actual services. A warning is useful because it points to a concrete account, not because clearing a list is an end in itself.
Do not replace many passwords in a rushed session if you cannot verify each result. For a critical account, confirm the recovery email, trusted number or other supported recovery method while you still have access. Keep recovery material according to the service's instructions, separate from a casual note that someone else can open.
Handle duplicates without deleting the only working record
If two entries appear similar, inspect their domains and usernames and test the intended sign-in. One may be an old login address, a related subdomain or a different household member's account. Rename or organize only after establishing what each entry represents. Deleting the wrong stored record does not delete the service account, but it can remove the information you needed to reach it.
If a credential is missing on another Apple device, inspect compatible software and the relevant iCloud Passwords and Keychain synchronization settings. A device showing the app does not prove that the expected account data has synchronized. Avoid signing out broadly as a first troubleshooting action.
Keep the app and the account relationship aligned
The useful result is not a perfectly empty warning screen. It is that each important account has a known identifier, a working appropriate credential and a recovery route you understand. Review entries when you close an account or change its email, rather than letting the password manager become a collection of unexplained historical names.
The 2024 standalone app makes that review easier to reach. Pair it with two-factor authentication planning and the phishing check: a well-managed credential still needs to be used only at the genuine service.
Sources & further reading
Apple’s documentation supports the feature details. The scenarios and decision sequences above are CJVV’s editorial guidance.