Importing secrets

Adopting Kutrion 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
Kutrion 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 Kutrion, 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 Kutrion’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 need a credential before they are created. A session that authenticates with a local private key or an OS keychain entry — which Kutrion cannot read — is marked as needing one. In the web app and the Terminal app, the review step groups those sites (by the export’s own folders, where it has them) and lets you add one credential per group: type the password or paste the private key once and every SSH site in the group is linked to it. The credential is saved to the vault you chose, injection-only unless you untick it. You can also type a username and password on a single site instead. Sites still without a credential are skipped and listed.
• The result says how many hosts are ready. The count is of connections created and linked to a credential, so each one can be opened straight away.

Connection import is available in the web app and the Terminal app, and in the mobile app once it is published. The mobile app does not offer the per-group credential step yet. The CLI has no import command.

Exporting a vault

A vault exports as JSON — the same shape the Kutrion 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.