Importing secrets

Adopting VaultTerm should not mean re-entering every secret by hand. The vault imports from the common password managers, and the connection list imports from the SSH, SFTP and FTP clients you already use, so you can move what you have and start from there.

Importing secrets

The importer auto-detects the source from the file you upload. Supported sources:

Source	Format
Credential Exchange (CXF / CXP)	JSON — the FIDO Alliance interchange format, exported by 1Password, Apple Passwords, Bitwarden, Proton and others. Carries logins, passkeys, TOTP, notes, cards, SSH and API keys.
1Password	CSV
Bitwarden	JSON, CSV
Dashlane	JSON, CSV
LastPass	CSV
KeePass / KeePassXC	CSV
Keeper	JSON
Proton Pass	JSON
NordPass	CSV
RoboForm	CSV
Apple Passwords	CSV
Chrome / Edge	CSV
Firefox	CSV
iTerm2 dynamic profiles	JSON — SSH profiles come across as notes recording the connection target
SecureCRT session	.ini — the session target; SecureCRT stores its passwords encrypted and they are not importable
SSH private key	a PEM or OpenSSH key file, imported as an SSH_KEY
VaultTerm CSV / JSON	the generic template and the native export

Imported records land as the appropriate secret type, so a password comes in as a PASSWORD, an SSH key as an SSH_KEY, and so on. A passphrase-protected private key is refused rather than stored unusable — strip the passphrase first (ssh-keygen -p -f key) and import it again.

How an import works

1. Export your data from the source tool.
2. In VaultTerm, choose the vault the records should land in.
3. Upload the export file. The matching importer is detected from the file; you can also pick it.
4. Review the parsed records and any warnings, then confirm.
5. The records are stored under envelope encryption as their detected secret types.

After import, run a credential health scan so anything weak, old or reused that came across is flagged for rotation.

Importing connection profiles

Connections are imported separately from secrets, because a connection is a host, port, protocol and login user rather than a value. Supported sources:

Source	File
OpenSSH	~/.ssh/config
FileZilla	sitemanager.xml
WinSCP	WinSCP.ini
PuTTY	a .reg export of saved sessions
MobaXterm	.ini / .mxtsessions
mRemoteNG	confCons.xml
Cyberduck	.duck bookmark
Termius	JSON export (best-effort — Termius is cloud-first and its export is partial)

Each site is mapped onto one of VaultTerm’s protocols — SFTP, FTP, FTPS or WebDAV. SSH sessions from OpenSSH and PuTTY come across as SFTP connections, which is the same brokered SSH path an interactive shell uses; a PuTTY session that is not SSH is reported and skipped.

The flow mirrors the secret import: upload the file, review the discovered sites, pick the vault any embedded secrets should land in, and confirm. Then:

• Nothing is duplicated. A site matching a connection you already have — same protocol, host, port and login user — is skipped. Re-importing after changing a remote base folder updates that folder in place instead of doing nothing.
• Embedded passwords are re-sealed, not kept. Where an export carries a password, it is decoded only to store it in your chosen vault as a login credential the new connection links to. The upload itself is not retained.
• Sites with no importable password are reported, not created. A session that authenticates with a local private key or an OS keychain entry — which VaultTerm cannot read — is listed as skipped, and you create that connection yourself with an SSH_KEY credential attached. WinSCP, PuTTY and SecureCRT sessions that keep their secret outside the export land here.

Connection import is available in the web app and the mobile app. The CLI has no import command.

Exporting a vault

A vault exports as JSON — the same shape the VaultTerm JSON importer reads, so an export can be re-imported. There is no CSV vault export.

• Export is a read. Anyone with read access to the vault can export it, including a VIEWER. It is not restricted to org admins, and that is deliberate rather than an oversight: VIEWER already means “may read the secrets in this vault”, and the export is the same permission exercised in bulk. If you need someone who can see a vault’s contents but not take a copy of them, the control is not to grant read. The admin-only, CSV export people sometimes have in mind is the organization member list — a different endpoint holding no secrets.
• A step-up may be required. The export is classed as a critical action, so a session that looks anomalous — including a burst of reads that looks scripted — is asked to re-verify a second factor first, and is refused outright if the signal is strong enough.
• Injection-only credentials are skipped. They are excluded from the file rather than exported with a blank value — see SSH broker overview.
• Every export is audited, with the number of records that left.

An export is a plaintext copy of secret material. Treat the file accordingly.

Where to go next

• See how imported records are typed in Secret types.
• Clean up anything weak that came across in Credential health.
• Set up who can share what in Sharing and rotation.
• Open a session on an imported connection in Connecting to hosts.