Liscaragh Migrate › Help › How we store your credentials

How we store your credentials

Liscaragh Migrate holds up to three kinds of credential, depending on your source: a Microsoft 365 certificate, a Datto Workplace secret, and, for a files-and-folders source, network-share sign-ins. All three are protected using the operating system's own facilities, held only on your device, and never sent to Liscaragh Software or any Liscaragh service.

Microsoft 365: a non-exportable certificate

The destination connection uses certificate-based authentication rather than a stored password. When you run the Microsoft 365 setup wizard, it generates a certificate directly on your machine and places its private key in your Windows certificate store, marked non-exportable. Only the public key is ever uploaded, to the Microsoft 365 app registration; the private key cannot leave the device it was generated on, even deliberately. No .pfx file is written, so there is no certificate file to end up copied, emailed or left on a desktop.

The practical consequence: there is no Microsoft 365 account password for the tool to store at all, and recovering from a lost or rebuilt machine means re-running the wizard to generate a fresh certificate, not restoring an old one.

Datto Workplace: an encrypted secret

The Datto Workplace Client ID and Secret you enter under Settings > API settings are stored locally and protected using Windows' own data protection facilities (DPAPI), tied to your Windows user account. The Secret is never written into any file the tool ships, and is never transmitted anywhere except to Datto Workplace itself, as part of authenticating each API call. Only the account that encrypted it, on the machine that encrypted it, can decrypt it again.

Network shares: Windows Credential Manager

A files-and-folders migration from a network share sometimes needs a different account to reach it than the one running the tool. Where you choose to store that sign-in, either from Share sign-ins… or when prompted after a folder fails to open, it is saved into Windows' own Credential Manager using the operating system's credential-storage API. The password is never written into any file the tool manages, never shown in a command window, and never retrieved or displayed by the tool itself once saved; Windows presents it automatically when the relevant server is next reached, including during a scheduled run.

Because it is stored in Windows Credential Manager rather than by the tool, you can review, replace or remove it at any time, from inside the tool or directly through Windows' own Credential Manager in Control Panel, independently of Liscaragh Migrate.

What this adds up to

• Every credential is protected by the operating system, not by code the tool writes itself: DPAPI for the Datto secret and the config file it might otherwise sit in, the Windows certificate store's non-exportable flag for Microsoft 365, and Windows Credential Manager for network-share sign-ins.
• Nothing above is reversible by reading a file off the disk. A copy of the config file or the job folder, on its own, does not hand over a working credential; decryption is bound to the Windows user account that created it.
• If you use Help > Email support, the support file it builds has API secrets and access tokens stripped automatically before it is packaged, so a support request cannot accidentally leak one.
• None of this replaces good account hygiene on your side: using an appropriately scoped, least-privilege account for each connection, and revoking anything migration-specific once it is no longer needed, remains your responsibility. See what we expect from you.