Self-hosted photo libraries often contain location history, family records, identity documents, and years of personal images. Immich's access model includes individual accounts, partner sharing, albums, public links, API keys, and administrator-managed external libraries. A review that checks only the login page misses most of the ways data can leave the account boundary.
Immich partner sharing is one example. The documentation says a partner can view all non-archived and non-trashed photos and videos, including metadata such as GPS information, and can access assets through shared links and albums. Partner sharing is one-way, and the owner can remove the partner in account settings. That makes partner status a high-value relationship.
Separate accounts from shared libraries
Each Immich user has an account and devices. An external library belongs to one user and scans files from a path on the server. External library management requires administrator access, and the administrator chooses the library owner. A read-write external library can delete an original file, while a read-only library is a safer choice for an archive that another system manages.
Document the ownership of every external library and the filesystem path behind it. A library owner with an API key may expose photos that the administrator intended to keep separate. Check whether the storage mount is read-only for the Immich container, whether the path is backed up, and which user account can trigger a rescan.
Review sharing and API keys
Album sharing can grant viewer or editor access. Public shared links can allow uploads or downloads depending on the link. A link is a bearer capability even when it is long and random. Review active links, their expiry, and whether search engines or messaging clients can index them.
User settings allow each user to generate API keys. Store those keys as credentials and associate them with the user who created them. Disabling a user should include an inventory and revocation of the user's keys and any integrations that rely on them. Test partner removal and shared-link revocation from a second unauthenticated client.
What the ZoomEye observation shows
The count-only run used sub_type=all, page 1, and page size 1. app="Immich" returned no matches, title="Immich" returned 524, and http.body="Immich" returned 51,310. The title result is a better starting point than the broad body count, but it still needs ownership confirmation. A missing app fingerprint may reflect a reverse proxy, custom branding, or a fingerprint not present in the current index.
Combine public observations with cloud storage inventory and DNS records. Do not request a shared link or attempt account access on an unrelated instance. For an owned deployment, check whether the server is reachable only through the intended network path.
Controls that matter
Require strong authentication for every human account. Review partners and administrators on a schedule. Use read-only mounts for external archives unless deletion is explicitly required. Back up the database and originals separately, monitor login and link activity, and test the restore path.
The key question is not whether Immich requires a password. It is which identities and links can reach which library, and how quickly that access can be removed.