Protecting identity

Identity Security Best Practices

When using a single sign-on identity provider (IdP) for accessing Palantir Foundry, there are security best practices you should observe.

Use Strong Multi-Factor Authentication (MFA)

Palantir strongly advocates for proof of identity beyond the traditional use of username + password. Multi-factor authentication is mandatory for our software products. If you are using your own implementation of multi-factor authentication in your identity provider, you should require strong forms of authentication.

Examples of strong forms of authentication (in approximate order of preference):

• Connected hardware tokens, such as FIDO2-compatible USB security tokens (e.g., YubiKey, Google Titan) or CAC smartcards
• Disconnected hardware tokens, such as one-time password (OTP) token generators (e.g., RSA SecurID, Thales SafeNet)
• Software tokens, such as mobile device authenticator applications (e.g., Microsoft Authenticator, Google Authenticator)
  • Use of OTP generators is preferable to push notifications on mobile devices
• Biometrics, such as fingerprint or facial recognition (e.g., Apple Touch ID and Face ID, Windows Hello)

Other forms of MFA, such as SMS-based OTPs (text message), email OTPs and two-step authentication (clicking a link), or security questions are not considered strong forms of authentication and should be disused in favor of other methods.

If you do not have mandatory multi-factor authentication on your identity provider, our products have native support for multi-factor authentication.

Require Periodic Re-Authentication

Palantir Foundry intentionally mandates a relatively short maximum session lifetime to force periodic re-authentication against the identity provider. As sessions tokens can be stolen by adversaries and potentially be abused for their duration, enforcing a relatively short lifespan for all user sessions provides some assurance that any misuse is time-restricted.

For the same reason, you should ensure that the lifetime of the session tokens generated by your identity provider is not overly permissive.

Implement Zero Trust Security Principles

If you use a modern identity provider, you should enable and use Zero Trust technologies and strategies. Such technologies may include conditional access, device health or posture assessments, strong multi-factor authentication claims, and related controls. Refer to your identity provider documentation for what features are available, and how you can implement them.

Best practices for a Zero Trust security model include:

• Do not trust devices or users based on weak security indicators. This includes software-based machine certificates, single-factor authentication, or network location.
• Do not exempt users or devices from mandatory security controls.
• Require recent strong-multi factor authentication for access to sensitive resources.
• Require device security or health attestations or assessments as a condition for access.
• Require unusual logons or activity to require re-authentication.

Strictly Manage Service Accounts

Service accounts often have broadly-permissive access to sensitive data, and tend to be poorly secured in comparison to a standard user account. This makes them attractive targets for adversaries.

Pitfalls of service account management include:

• Service accounts may be accessible to multiple people.
• Service accounts may not have multi-factor authentication enabled.
• Service accounts may not have their credentials rotated after people leave your organization.
• Service accounts may have credentials or tokens hardcoded in scripts or applications.

If you use service accounts with Palantir Foundry, it's critical you safeguard them to protect your data.

Best practices for service account management include:

• Ensure each service account is documented, has a named owner, and is periodically reviewed for appropriateness.
• Configure your identity provider to only allow your service accounts to authenticate from specific IP addresses.
• Require multi-factor authentication for service accounts, where possible.
• Store service account credential material in a privileged access management (PAM) solution.
• Require multi-party authentication to gain access to service account credential material.
• Rotate service account credential material as needed based on team changes or leavers.
• Strictly monitor service account behavior, logons, and credential material.

Monitor Audit Logs

Central Auth

Central Auth is a Palantir-managed Microsoft Entra ID (Azure AD) identity provider. Central Auth is managed by the Palantir Information Security team, and is designed to be a security-first authentication solution for customers who do not have their own identity provider, or have not yet been able to integrate their identity provider with Foundry.

If you do not have an identity provider for your Foundry installation, we may be able to provide access via Central Auth for you. Contact your Palantir representative for more information.

Central Auth Security

Central Auth may be integrated with your Foundry installation as a SAML Multipass realm. When integrated, user account provisioning and deprovisioning is managed by Palantir. Groups, markings, and other Platform security features are still managed by you.

All Central Auth accounts must meet strict security controls:

• High-strength passwords and strong multi-factor authentication are required.
• Central Auth users may need to perform re-authentication based upon suspicious logons or behavior.
• Accounts that remain unused for more than 30 days may be disabled without notice.