ProductShieldMSPPricingCompareBlogDocsStart for FreeSign InTR
Security

We sell a security product.
So we explain our own security model first.

This page is not a marketing slogan; it's a technical summary of which data Dynacop processes, which it never has access to, where decisions are enforced, and how to reach us when you find a vulnerability.

Trust boundaries
Windows sign-in screen
Credential Provider — no network access
Local Dynacop service — secrets in DPAPI
HMAC-signed HTTPS
Dynacop cloud

What we see — and what we never see

The data model is the first security decision. Dynacop is not a monitoring tool; it collects only what sign-in security requires.

We never see
✕ Your Windows passwords — Windows verifies them; Dynacop never sees, transmits, or stores them
✕ Your screen, files, or keystrokes — the agent is not a monitoring or recording tool
✕ In-session activity — Dynacop stands at the door; it doesn't watch what you do inside
We process (as the job requires)
✓ Sign-in events: who, on which machine, when, which session type (console/RDP), from which IP
✓ Attack attempts: source IP, attempt count, targeted service (RDP/SSH)
✓ Machine inventory: essentials needed for protection, such as hostname and open ports
✓ Person identity: name and email (for invites/enrollment) plus the verification factor

Policy is managed centrally; secrets stay protected on the machine.

The architecture rests on two one-sentence principles: policy and decisions are distributed from the center; and every secret on the machine is protected by the operating system's encryption.

A fake "allow" can't be forged

Online, the cloud makes the decision; offline behavior follows policy distributed from the cloud in encrypted form. In both cases, tampering with files on the machine can't produce a valid allow: every request between the agent and the cloud is HMAC-SHA256-signed with a per-machine secret, and a tampered or stale request is rejected.

The lock-screen component never touches the network

The sign-in component running on Windows' secure desktop makes no network connections and holds no secrets; all networking and secrets live in the separate agent service. The attack surface is deliberately kept small.

On-machine secrets are DPAPI-encrypted

Offline verification keys, policy, and recovery codes are encrypted on the machine with Windows DPAPI (machine scope) — copying the files doesn't reveal their contents.

Codes are single-use

Verification codes follow RFC 6238, and the same code is never accepted twice — including during offline verification. Repeated wrong codes temporarily lock the account.

The management panel is protected by the same security principles.

The management console can't be weaker than the systems it protects.

Passwordless sign-in

The panel has no passwords: email verification plus mandatory TOTP plus trusted devices. There's no panel password to steal, and sessions and devices can be revoked individually from your account.

Every endpoint passes an authorization check

Every management action is subject to a role-permission check; roles are bounded by scope (down to per-customer for MSPs). The last Owner can't be removed by accident.

Admin actions are written to the audit log

Panel sign-ins, verification attempts, and who changed which setting are kept in the audit trail. Passwords, codes, and key fields are masked in logs.

Machines enroll only with a claim code

A machine joins your workspace only with a claim code obtained from the panel; codes are time-limited, use-limited, and revocable. A random installation can't add itself to your environment.

Security is not locking you out.

You decide what happens when the cloud is unreachable: the default behavior locks nobody out, strict mode verifies codes locally on the machine, and single-use recovery codes work in every case. Billing problems never turn into sign-in blocks.

The full offline behavior →

Privacy posture

IP enrichment on our own infrastructure

Country/ISP details for attacker IPs are resolved from a database we host ourselves — your IPs are not sent to third-party services for enrichment.

No usernames in outbound data

The Threat Feed API deliberately carries no targeted account names, and weekly report emails never include raw IPs or usernames — detail stays in the panel.

Customer isolation

In the MSP structure every customer lives in its own workspace; data, people, and policies never cross the boundary. A customer signing in sees only their own environment.

Verify the installer signature yourself

Our installers are Authenticode-signed. Don't take our word for it; have Windows verify the signature.

Expected publisherForty2 LLC

Installers are Authenticode-signed using Microsoft Artifact Signing.

With the Windows UI
  1. Right-click the installer → Properties
  2. Open the Digital Signatures tab
  3. Select the Forty2 LLC signature → Details
  4. Confirm "This digital signature is OK"
With PowerShell
Get-AuthenticodeSignature .\DynacopSetup.msi |
    Format-List Status, StatusMessage, SignerCertificate
Expected result
Status  : Valid
Subject : CN=Forty2 LLC, O=Forty2 LLC, ...
With SignTool
signtool verify /pa /v DynacopSetup.msi

Signatures are timestamped; older releases stay valid even after certificates rotate. A signature proves two things — that the file was published by Forty2 LLC and hasn't been modified since signing. It does not guarantee the software is free of defects.

Found a vulnerability?

We welcome good-faith reports from security researchers. Send us your findings — with reproduction steps if possible. This section is also our disclosure policy; our machine-readable address is /.well-known/security.txt

Scope
  • dynacop.com and its subdomains (including app, api)
  • The Dynacop Windows agent and sign-in component
  • The Threat Feed API and the panel
What we ask of you
  • Don't access customer data that isn't yours; if you reach it accidentally, stop and report
  • Avoid tests that would disrupt service (DoS, brute-force scanning)
  • Social engineering and physical attacks are out of scope
  • Coordinate public disclosure with us until a fix ships
Our promise
  • We confirm receipt of your report within 2 business days
  • We fix confirmed findings promptly and keep you informed throughout
  • We won't pursue legal action for good-faith research that follows these rules
  • We'll credit you in the fix notes if you wish — we don't run a bounty program at this time

security@dynacop.com · subject: "Security report"

Security — frequently asked questions

Do you see my Windows password?

No — at no stage. Windows verifies the password; Dynacop never sees, transmits, or stores it. What Dynacop verifies is the person, via the code on their phone.

What does the agent collect on the machine?

Sign-in events, failed-attempt/attack telemetry, and basic machine inventory (hostname, open ports). It doesn't watch screens, files, or keystrokes and doesn't look at what you do inside a session — it is not a monitoring tool.

How do I know the installer really came from you?

From the signature. In the file's Digital Signatures tab you should see the publisher Forty2 LLC and "This digital signature is OK"; you can also verify with PowerShell or SignTool. The steps are in the signature section of this page.

Where do I report a security vulnerability?

Write to security@dynacop.com with the subject "Security report"; our machine-readable address is in /.well-known/security.txt. We confirm receipt within 2 business days and fix confirmed findings promptly. Scope and rules are in the disclosure section of this page.

Your first 10 users are free.
You've read the model; now try it in about 4 minutes.

No credit card required · No minimum purchase