Can You Leave a Password Manager With a Complete, Verifiable Copy of Your Data?

A password manager can become the index to a person's digital life: passwords, recovery codes, authenticator seeds, notes, documents, photos, videos, and the account context needed to understand them. If leaving the product produces only a password CSV, the user may technically receive an export while losing much of the vault's meaning.

Portability also has a security paradox. A useful migration copy must be readable by another tool or by the owner, but readable secrets no longer have the vault's encryption boundary. A responsible export therefore needs both broad coverage and an unmistakable handoff of responsibility.

Quick answer

Yes—with explicit limits. Krypt can create a decrypted export package containing separate ZIP archives for photos, videos, documents, passwords, notes, authenticator data, cards, albums, and optional activity logs. It also writes export_manifest.json to describe the package and checksums.sha256 so the owner can detect later changes or corruption.

The export is deliberately plaintext, not a recovery backup. Krypt requires the user to type EXPORT before it begins, warns that anyone with the files can read them, pauses auto-lock during the job, and restores auto-lock when the export completes, fails, or is canceled. Passkeys and vault recovery secrets are excluded. A completed export is the user's responsibility to verify, protect, move, and remove.

What a complete export should let you answer

“Export supported” is not a sufficient portability test. Before trusting any password manager, ask four more precise questions:

1. What categories are included? A password-only file is incomplete if the vault also stores notes, files, TOTP seeds, identity cards, albums, or recovery context.
2. Can a person inspect the result? Proprietary encrypted blobs may be useful for same-product recovery but are not necessarily a practical exit path.
3. Can change or corruption be detected? Counts, manifests, and reproducible digests make verification possible instead of relying on a success message.
4. What is intentionally excluded? The export should name omissions rather than letting users discover them after wiping an old device.

The UK National Cyber Security Centre makes the core tradeoff explicit in its password-manager buyer guidance: plaintext export can make replacement easier, but exported passwords are no longer protected. It recommends guarding the function against accidental or malicious use and defining how the files will be handled. Portability is a security feature only when the transition is controlled.

Inside Krypt's category export

Krypt starts from the currently unlocked vault and asks the user to select a destination. On mobile, the app uses a temporary application directory for the generated package so it can be shared; on desktop, the user selects a folder. The confirmation screen states that the archives will be readable and accepts only the exact confirmation word EXPORT.

The job then creates an export directory and processes categories separately. Low-impact mode is enabled by default, uses stored ZIP entries rather than compression, and yields between files to reduce pressure on the device. The screen exposes pause, resume, and cancel controls. Users may also choose whether to include Trash items and whether to create the optional activity archive.

The package uses these category archives:

• photos.zip, videos.zip, and documents.zip contain decrypted file content organized by category.
• passwords.zip contains readable password records, including associated fields that belong to those records.
• notes.zip contains decrypted secure-note content.
• authenticators.zip contains TOTP data in authenticators.json and a separate text list only for values already stored as otpauth:// URIs. Raw Base32 secrets are exported as data but are not converted into importable URIs.
• cards.zip contains card records and their associated front or back files where present.
• albums.zip records albums and album-item relationships so organization is not reduced to a pile of media files.
• activity.zip contains local access-log rows when the optional activity-log setting is enabled.

Each category ZIP receives its own internal manifest.json with the category, creation time, decrypted status, and item count. The top-level export_manifest.json records creation and completion times, vault type, selected options, impact mode, archive results, folders, warnings, and the fact that passkeys are not included. That separation makes an error in one category visible without turning the entire export into one opaque archive.

What SHA-256 verification does—and does not—prove

After each ZIP is closed, Krypt computes its SHA-256 digest. It also hashes export_manifest.json, then writes the archive and manifest digests to checksums.sha256. NIST FIPS 180-4 specifies SHA-256 as part of the Secure Hash Standard and describes message digests as a way to detect whether messages have changed.

A one-byte change produces a different digest with overwhelming probability. If you copy the export to another drive, recalculate the listed hashes at the destination and compare them with the original checksum list. On macOS or Linux, a common verification command run inside the export directory is:

shasum -a 256 -c checksums.sha256

A successful check shows that the current bytes match the checksum list you supplied. It does not show that the ZIPs are encrypted. It does not prove that Krypt—or any particular person—authored them. An attacker who can replace both an archive and checksums.sha256 can create a self-consistent altered package. Preserve the original checksum file through a trusted path if authenticity of the comparison matters.

Why exclusions belong in the migration plan

Krypt does not place passkeys into these readable ZIPs. The top-level manifest marks passkeys_included as false. The export screen also states that vault recovery secrets are excluded. A user must therefore plan passkey transfer or re-enrollment separately and retain the matching Recovery Kit or Rescue Key needed for encrypted backup recovery.

That is not the same as an incomplete, undocumented failure. Some credentials are intentionally outside a generic plaintext interchange package. The important operational rule is to verify those exclusions before deleting Krypt, erasing the source device, or assuming another manager can recreate every authentication method.

Cancellation removes the export directory, not every trace

During controlled archive work, Krypt checks the pause/cancel controller between operations. When cancellation is observed, the export service recursively deletes the in-progress export directory and the interface reports that partial files were removed. Auto-lock is then restored in the screen's cleanup path.

This is cleanup, not a universal secure-overwrite guarantee. Modern flash storage, copy-on-write file systems, caches, cloud-sync clients, backups, and files already shared elsewhere may retain recoverable copies. A failure at a point outside the controlled cancellation path may also leave partial output that needs manual review. Krypt does not promise secure overwrite of every partial ZIP or of completed exports, and it does not automatically destroy a completed package after the user moves or shares it.

NIST SP 800-88 Revision 2 defines sanitization as making access to target data infeasible for a chosen level of effort and treats the technique as a decision tied to media, sensitivity, validation, and approved controls. Deleting a directory is useful application cleanup; it should not be described as equivalent to validated media sanitization.

Krypt's answer: portability that can be inspected

Krypt is a zero-knowledge password manager built around local ownership. Its decrypted export is designed as an exit and inspection path rather than a vendor-only restore artifact: categories are separated, package contents are described, omissions are explicit, warnings are recorded, and file digests can be recalculated independently.

The design does not pretend that portability is risk-free. Typed confirmation makes the transition deliberate. Plaintext warnings remain in the interface and manifest. Auto-lock is paused only for the job and restored afterward. Cancel requests clean the in-progress directory when observed. Most importantly, the completed result is not mislabeled as protected just because it came from an encrypted vault.

Safe export and verification checklist

1. Review the destination first. Prefer a trusted local encrypted volume, and pause consumer cloud sync or indexing if it would copy readable secrets automatically.
2. Keep Krypt open and powered during the export. Large photo and video vaults can take several minutes or longer.
3. Choose whether Trash items and activity logs belong in the package. More complete is not always more private.
4. Type EXPORT only after reading the plaintext warning and confirming that nobody else can access the destination.
5. Wait for the completed result. Do not treat a directory that appeared early as a finished export.
6. Open export_manifest.json. Review archive counts, warnings, selected options, timestamps, and the passkey exclusion.
7. Run SHA-256 verification before and after copying. Keep the original checksums.sha256 through a trusted path.
8. Open representative files from every required category and compare them with the source vault. A checksum validates bytes, not semantic completeness.
9. Plan passkey migration and encrypted-vault recovery separately. Do not erase the old device until both paths are tested.
10. Import into the destination on a trusted device, verify critical records, then encrypt or remove leftover plaintext copies according to the storage medium and your threat model.

For the product workflow and format distinctions, see Krypt's Export Vault guide. A decrypted portability export and an encrypted recovery backup solve different problems; keeping that distinction clear prevents an exit file from becoming the easiest copy of the vault to steal.

FAQ

Is a Krypt decrypted export encrypted?

No. The category ZIP archives are deliberately readable so you can inspect or migrate the data. Anyone who obtains the completed files can read the exported content, so move them only through a trusted path and encrypt the storage or destination if you retain them.

What does checksums.sha256 prove?

It lets you recalculate SHA-256 digests and detect whether an archive or export_manifest.json changed after Krypt generated it. It does not encrypt the export, identify who created it, or prove authorship, because someone who can replace the files may also replace the checksum list.

Does Krypt export passkeys and Recovery Kit secrets?

No. Krypt marks passkeys as excluded in export_manifest.json, and the export screen states that passkeys and vault recovery secrets are excluded. Keep your passkey migration plan and matching Recovery Kit or Rescue Key separate from this readable data export.

Technical references

The UK National Cyber Security Centre's Password manager buyers guide explains both the portability value and exposure risk of plaintext exports and recommends protecting and governing the function. NIST FIPS 180-4, Secure Hash Standard specifies SHA-256 and explains how message digests detect changed content. NIST SP 800-88 Revision 2, Guidelines for Media Sanitization defines sanitization and frames deletion assurance around media, sensitivity, technique, and validation.

Use Krypt to keep control of your encrypted vault—and to produce an inspectable, verifiable exit copy when you deliberately need one.