Trust Center

Security at Native Security

A security product must be held to a higher standard. Here is how we operate — our access model, encryption practices, and what we do and do not see in your cloud environment.

Data Access Model

Native Security operates exclusively through read-only API access to cloud provider management planes. We call AWS Organizations APIs, Azure Policy REST, and GCP Organization Policy APIs — not data plane services. We never access S3 objects, RDS data, VM disks, or any workload data. Token scopes are documented for each provider in our Quickstart guide.

  • Read-only IAM role in AWS (organizations:List*, organizations:Describe*)
  • App Registration with Reader role at Azure Management Group scope
  • GCP Service Account with roles/orgpolicy.policyViewer
Encryption

All communication between your cloud accounts and Native Security infrastructure is encrypted in transit. Policy metadata stored at rest is encrypted using AES-256.

  • TLS 1.3 for all API connections (TLS 1.2 minimum; 1.0 and 1.1 disabled)
  • AES-256-GCM at rest for all stored policy metadata
  • API keys encrypted at rest; displayed once at creation, never again
Access Controls

Internal access to production systems follows least-privilege RBAC. Engineering access to customer org metadata requires MFA and is logged to an immutable audit trail.

  • MFA required for all internal accounts with production access
  • RBAC: read-access, write-access, and admin are separate roles with separate credentials
  • All internal access events logged; logs retained for 12 months
Vulnerability Disclosure

We welcome security research. If you find a vulnerability in Native Security, report it to us before disclosing publicly and we will work with you on a coordinated disclosure timeline.

  • Responsible disclosure: email [email protected]
  • We acknowledge all reports within 2 business days
  • We target a 30-day fix timeline for critical vulnerabilities
Compliance Design

Native Security is designed with SOC 2 Type II controls in mind — we are not claiming SOC 2 certification at this stage. Our internal controls, logging, and access model are built to support future certification.

  • Designed with SOC 2 CC6 (Logical Access) controls in mind
  • Change management: all production deploys require peer review and CI passing
  • We do not claim SOC 2, ISO 27001, or HIPAA certification
Infrastructure

Native Security runs on AWS. Our infrastructure is version-controlled, deployed via CI/CD, and subject to the same SCP guardrails our product enforces for customers.

  • Hosted in AWS us-east-1 with failover to us-west-2
  • Infrastructure-as-Code (Terraform) for all production resources
  • SCPs applied to our own AWS organization — we eat our own cooking

Questions about our security posture?

Security teams evaluating Native Security can request our access model documentation, token scope list, and current infrastructure configuration. Email us directly — we answer technical questions, not marketing ones.