Skip to content
docs

Type at least two characters. Press Enter for full results.

    FIPS 140-3 mode

    View as MarkdownOpen in ChatGPTOpen in Claude

    Outpost’s Depot server and agent are built with the Go Cryptographic Module v1.0.0, CMVP certificate #5247, and run it in FIPS 140-3 mode by default. This page explains what that covers, the one place Outpost uses an algorithm that is not FIPS-approved, and how to turn that off. It is for anyone who has to answer a questionnaire or an auditor about the cryptography in their endpoint management.

    What it covers

    Section titled “What it covers”

    Every released Depot and agent build is built this way. There is no separate FIPS edition to install and no setting to turn it on.

    In FIPS 140-3 mode, the cryptography in these programs comes from the validated module and uses approved algorithms wherever the protocol allows:

    • Data Outpost protects. Anything Outpost encrypts, signs, hashes, or derives a key for uses approved algorithms: AES-GCM, SHA-2, HMAC, ECDSA and Ed25519 signatures, and PBKDF2 for password hashing.
    • Field encryption. Sensitive database columns, such as stored credentials, are sealed with AES-256-GCM before they are written, with each value bound to its table and column.
    • TLS in Outpost’s programs. TLS connections the Depot and the agent make or accept, including the agent’s mutual TLS connection to your Outpost, negotiate only FIPS-approved protocol versions, cipher suites, key exchanges, and signature algorithms.

    The OpenBSD agent is the one build without FIPS 140-3 mode, because the Go module does not support OpenBSD.

    The legacy NTLM exception

    Section titled “The legacy NTLM exception”

    Network discovery can push the agent onto Windows computers it finds. One of the three deploy methods, WinRM, signs in with NTLM. NTLM is built on MD4, MD5, RC4, and DES, none of which is FIPS 140-3 approved. Outpost uses them only to reach targets that require NTLM, and only for that sign-in. Nothing Outpost stores or sends to its own services uses them.

    The other two methods are not part of the exception:

    • SMB (Windows file sharing) deploys use Windows’ own authentication. Windows chooses Kerberos or NTLM for the connection, using its own cryptography and the “Network security: Restrict NTLM” group policy settings on your computers. To keep SMB off NTLM, use those group policies.
    • SSH deploys negotiate only approved key exchanges, ciphers, MACs, and host key types. A target that offers none of them refuses the connection.

    Turning the exception off

    Section titled “Turning the exception off”

    Set discovery.disable_legacy_ntlm to on in a profile that applies to the agents that run network discovery. It is off by default. If any applicable profile turns it on, it is on for that agent.

    With it on:

    • Outpost refuses a WinRM deploy with Legacy NTLM is disabled by policy., and the deploy dialog then shows WinRM as unavailable with that reason.
    • The agent checks its own policy again before every deploy and fails a WinRM job, so the refusal holds even if a request reaches it another way.

    SMB and SSH deploys keep working. Deploy to Windows computers over SMB, or install the agent on them another way. See Automation for how to set a profile setting.

    Limits

    Section titled “Limits”
    • FIPS 140-3 mode covers the Depot and the agent. It does not cover software Outpost does not build, such as the operating system, its TLS libraries, or the tools the agent runs on the endpoint.
    • Turning off legacy NTLM affects only Outpost’s WinRM deploys. It does not change NTLM use anywhere else on your network.
    Section titled “Related”

    Content is licensed CC BY 4.0. Code samples are MIT. Outpost and the Outpost mark are trademarks of Outpost Business Solutions, PBC and are not covered by either license.