Security

The connections Ledger syncs from are read-only: through them it never installs an agent, changes a policy, or writes back to any of the tools you connect. The connectors only read your data; the only requests that are not plain reads are the sign-in requests some of them make to obtain an access token and the Intune connector's request asking Microsoft to prepare a device export, and none of these changes anything in your tools. See each connector's own page under Connect a source for exactly which endpoints it calls and nothing more. Every stored credential is encrypted per customer with its own data key -- generated each time the credential is stored or rotated, bound to that customer's ID, and wrapped by a managed key store, with only the wrapped key stored beside the credential (never a single shared key) -- and a redaction filter scrubs credentials from log lines and error reports as a safeguard, with request bodies and local variables not sent to error reporting. Deleting a departing customer's stored credentials is currently a manual action by the Ledger team on request, with no automatic schedule and no promised deadline.

That read-only guarantee has one narrow, opt-in exception, and both parts of it are off unless a customer turns them on. Ledger can create a ticket in ConnectWise PSA or Autotask from an exception the customer chooses to act on, using a separate credential added for that purpose alone. It creates the ticket and, where it can, links the affected device; it never edits, closes or deletes a ticket, and it never changes a device, a policy or an agreement. Ticket creation is switched off unless your account has been enabled for it; see Tickets. Ledger can also send signed HTTPS messages when an exception is opened, resolved or suppressed, to an address the customer chooses. Each message carries the exception's id, rule code, severity and status, the client name, the device display name and the exception's own message text, and never a credential. Only public HTTPS addresses are accepted (checked when the webhook is saved and again at every send), redirects are not followed, every message is signed, and the signing secret is shown once; see Webhooks. Both are off by default and need an explicit opt-in for each connection or webhook. Ledger cannot verify who operates a public address a customer supplies, so a webhook address should be one the customer controls.

For the full picture -- data handling, subprocessors, breach-notification commitments, and deletion SLAs -- see the Trust page in the application, also linked from the footer of the sign-in page and the home page. Any value the Trust page has not yet confirmed is shown there as pending.

The same material is set out in more detail in the security questionnaire, the subprocessor list and data retention.