Welcome to JupiterOne's Trust Center. Our trusted platform is built by embedding security throughout the software development and delivery lifecycle. We follow rigorous operational security practices such as penetration testing, vulnerability assessments and strong internal access controls. We believe transparency is the key to winning trust — we publicly share how we operate, and work closely with our customers and partners to address their security needs. Our commitment to data privacy and security is embedded in every part of our business. Use this Trust Center to learn about our security posture and request access to our security documentation.
Documents
Featured Documents
AI
AI
We take the usage of AI seriously in our organization and work to ensure security and reliability of the AI.
Access Control
Access Control
Access is tightly monitored and controlled at our company. We are happy to provide more details about our access control practices upon request.
Data Privacy
Data Privacy
Privacy of customer data is top of mind. We follow industry best practices and follow all applicable privacy regulations.
Continuous Monitoring
Continuous Monitoring
We continuously monitor our systems for security threats and vulnerabilities. We are happy to provide more details about our continuous monitoring practices upon request.
CISA Secure By Design Pledge
CISA’s Secure by Design Pledge: A Blueprint for Resilient Software Security
In April 2024, the Cybersecurity and Infrastructure Security Agency (CISA) introduced its Secure by Design Pledge—a bold initiative to shift the burden of security away from end users and onto software manufacturers. Its mission is clear: embed security into the foundation of technology products, not bolt it on after the fact. At JupiterOne, we wholeheartedly support this movement. We view the pledge as a natural extension of our mission to empower security visibility and governance across digital environments. Here's how JupiterOne is putting these seven goals into action today:
-
Driving Adoption of Multi-Factor Authentication (MFA) JupiterOne Action: MFA is enforced by default for all administrative accounts. We support SSO with MFA compatibility across our platform. Users are proactively reminded to enable MFA with friendly, persistent nudges. How We're Measuring Progress: We track and publish MFA adoption metrics internally. We’re exploring future options for sharing anonymized data to contribute to industry benchmarks.
-
Eliminating Default Passwords JupiterOne Action: JupiterOne does not use default, hardcoded, or universal passwords anywhere in our systems. All authentication requires unique credentials or integration with secure identity providers. How We're Measuring Progress: Continuous internal reviews ensure secure configuration defaults. Legacy systems and integrations are regularly audited and updated to maintain best practices.
-
Reducing Entire Classes of Vulnerabilities JupiterOne Action: New development is conducted using memory-safe languages where applicable. Secure coding guidelines are enforced through code reviews and automated tools. We’ve adopted frameworks that prevent common vulnerabilities (e.g., parameterized queries, input validation). How We're Measuring Progress: Regular internal reporting tracks vulnerability types and root causes. We maintain a roadmap to address legacy code and eliminate technical debt.
-
Accelerating Security Patch Adoption JupiterOne Action: Patches and updates are deployed automatically across our SaaS infrastructure with no customer action required. Customers are notified of relevant fixes via release notes and our Trust portal. How We're Measuring Progress: We track patch deployment timelines internally. Feedback loops help us continually improve our update experience and transparency.
-
Implementing a Public Vulnerability Disclosure Policy (VDP) JupiterOne Action: We have a publicly available VDP. Researchers are encouraged to disclose vulnerabilities responsibly through our GitHub Security page or email. We provide safe harbor for good-faith security research. How We're Measuring Progress: All reported vulnerabilities are triaged, tracked, and disclosed transparently when applicable. We engage with the security community to continuously improve this process.
-
Ensuring Transparency in CVE Reporting JupiterOne Action: JupiterOne issues CVEs for high or critical vulnerabilities that impact our customers. Our disclosures include complete metadata such as CWE and CPE identifiers. How We're Measuring Progress: We maintain a consistent cadence of vulnerability reporting. Trends and lessons learned are used to drive proactive improvements in our software security lifecycle.
-
Enhancing Intrusion Detection and Auditability JupiterOne Action: Customers have access to comprehensive audit logs at no additional cost. Logs include user identity, access events, configuration changes, and more. We offer guidance on configuring alerting and log ingestion into SIEMs. How We're Measuring Progress: Documentation and support resources are regularly updated to reflect best practices. Product improvements are prioritized based on customer feedback and detection use cases.
Conclusion: Building Security Into Everything We Do The CISA Secure by Design Pledge challenges software vendors to take accountability for the safety of the digital world we’re building. At JupiterOne, we accept that challenge—and we’re already putting it into action. From MFA enforcement to CVE transparency, secure development to vulnerability disclosure, our commitment is clear: security is not a feature—it’s a foundation. We also believe in transparency and partnership. If you have concerns or discover a vulnerability in a JupiterOne product, please contact us at security@jupiterone.com or visit our GitHub security page for more information. Let’s build a safer digital future where security is a basic right…by design.
JupiterOne's Response to the 2022 OpenSSL 3 Vulnerabilities
After careful review of our infrastructure and SBOM, the JupiterOne team has determined that we are not currently vulnerable to the OpenSSL 3 vulnerabilities (CVE-2022-3602 and CVE-2022-3786) that were disclosed on November 1, 2022. We are continuing to search our environment for potential exposure and will update this page to reflect our latest findings.