Security posture

Built to be
audited. Not just
claimed.

This page covers everything a security engineer, CISO, or vendor risk assessor needs to evaluate Nantevo's security posture — authentication architecture, credential design, data handling, supply chain transparency, responsible disclosure, and penetration testing coordination.

Questions not answered here:
[email protected]

01 — Authentication architecture

The credential is in the transport layer.
No software on any device.

Nantevo's authentication model embeds client identity into the DoH endpoint URL itself — validated at the reverse proxy before the request reaches the DNS resolver. There is no agent, no kernel extension, no certificate to manage on endpoints. The credential pair is the security boundary.

Credential structure
# Every enrolled client receives a unique pair:

endpoint: r7mxk4bqe9yzw2nt6p3dh8f5a.nantevo.com
└─ 25 chars · a-z0-9 · ~129 bits

clientID: k9vw2mfx4bqt7nzy3p6rh8d5e
└─ 25 chars · a-z0-9 · ~129 bits

# DoH request path:
POST https://r7mxk...a.nantevo.com/q/k9vw2...e

# Proxy validation:
# nginx virtual host per endpoint subdomain:
vhost: r7mxk4bqe9yzw2nt6p3dh8f5a.nantevo.com
location ~ ^/q/{clientID}$
→ proxy_pass to resolver
location /
→ return 444 (silent drop)

# Authentication is structural — it is the
# nginx config itself. No runtime lookup.
# No credential store to compromise.
Entropy per field
~129 bits
Fields required
Both
Generation source
OS CSPRNG
Revocation time
Instant
Brute force resistance

~129 bits per field — computationally infeasible

At 25 characters of lowercase alphanumeric (36 symbols), each field carries log₂(36²⁵) ≈ 129 bits of entropy. Both fields must be correct simultaneously. The combined search space exceeds the energy budget of the observable universe for brute force at any foreseeable computing power, including quantum systems running Grover's algorithm.

Enumeration resistance

Silent drop on failure — no oracle signal

Unauthenticated or incorrectly authenticated requests receive no response — not a 401, not a timeout, not a connection reset. Silence. This eliminates oracle feedback that would allow an attacker to distinguish between a wrong endpoint and a wrong ClientID, or to confirm that a given endpoint exists at all. Scanning is structurally indistinguishable from sending to a nonexistent host.

Revocation

Remove the virtual host — the endpoint ceases to exist

Revoking a client means removing their nginx virtual host configuration and reloading nginx. There is no credential store to invalidate, no token to expire — the subdomain simply stops having a matching configuration. Future requests to that endpoint receive a 444 silent drop, indistinguishable from any other unauthenticated probe. No device action required, no MDM push, no agent to remove.

Attack surface

Authentication is structural — baked into nginx config, not runtime code

There is no credential store, no authentication service, and no Nantevo binary on any enrolled device. Authentication is the nginx virtual host configuration itself — a request either matches the location block for that ClientID or it doesn't. There is no runtime lookup to intercept, no database to compromise, no authentication middleware to attack. The attack surface that agent-based solutions introduce does not exist here.

Credential generation

Python secrets module — OS CSPRNG exclusively

All credential generation uses Python's secrets module, which draws from the operating system's cryptographically secure pseudorandom number generator. The random module is never used for security-sensitive values. The alphabet is lowercase alphanumeric (a–z, 0–9) — DNS-safe for subdomain use, maximizing entropy per character within the constraint that the DNS backend requires lowercase only for ClientIDs.

02 — Data handling & privacy

What is logged. What is not.
Where it lives. Who sees it.

DNS telemetry is security-sensitive data. Nantevo's logging policy is designed to give security teams the attribution and forensic data they need while minimizing the data collected and eliminating third-party exposure entirely.

Query metadata — logged by default

Timestamp, authenticated ClientID, DNS response code, resolution latency, and threat classification. This is the minimum needed for 1:1 device attribution and RoCi behavioral analysis. Retention window is configurable per organization.

Default · configurable retention

Queried domain — logged by default

The domain name being resolved is part of standard telemetry. This is what enables blocked domain event lists, RoCi's DGA entropy scoring, per-client behavioral baselines, and incident forensics. Without the domain, the security product cannot perform its core functions. Retention window is configurable per policy.

Standard telemetry · configurable retention

Third-party sharing — never

Your DNS telemetry is never sold, shared with, or accessible by any third party for any purpose — including advertising, analytics, or threat intelligence aggregation. It is not used to improve Nantevo's general threat model without explicit consent. It belongs to your organization.

Zero sharing · zero advertising
What Nantevo explicitly does not do

No deep packet inspection

DNS query content is not inspected beyond the domain string. HTTPS payloads are never examined. The DoH transport encrypts query content end to end.

No behavioral profiling for advertising

DNS query patterns are analyzed exclusively for security threat detection. They are never used to infer user interests, demographics, or behavior for any commercial purpose.

No cross-customer data correlation

Telemetry from one customer is never used to inform threat decisions for another customer without explicit opt-in. Per-client baselines are isolated per account.

No query data egress from on-premise deployments

On-premise appliance deployments resolve DNS locally. The domains your devices resolve stay within your network boundary. Only anonymized RoCi threat signal metadata streams outbound — no query records, no domain names, no device identifiers.

03 — Supply chain & open source stack

No proprietary black boxes
in the resolution path.

Nantevo's resolver stack is built entirely on open source components with well-understood licenses. Every piece of software in the critical query path can be audited independently. This is not a marketing claim — it's a consequence of how the system was built.

Component Role in stack License Notes
FreeBSD Host operating system for all resolver nodes BSD 2-Clause Permissive — no distribution obligations. 20+ years of production use across the founding team's infrastructure history.
BastilleBSD Jail-based container isolation for resolver stack components BSD 2-Clause Created by Nantevo's founder. Open source, globally deployed in EU telecoms and hotel infrastructure.
Nginx Reverse proxy — TLS termination and credential validation layer BSD 2-Clause Open source version. Permissive license. No proprietary modules in the authentication path.
AdGuard Home DNS resolver and threat intelligence filtering engine GPL v3 GPL v3 — not AGPL. Network service use carries no GPL obligations. Nantevo's proprietary layers communicate via API, not code linkage — no derivative work relationship.
Python 3 Management tooling, credential generation, MDM profile generation PSF License Permissive. secrets module used exclusively for all credential generation — OS CSPRNG backed.
Flask Dashboard and client portal API layer BSD 3-Clause Permissive. No distribution obligations. Well-audited dependency tree.
Let's Encrypt / ACME Automated TLS certificate provisioning and rotation Mozilla Public License Certificates rotate automatically on 60-day cycle via cron-managed ACME client. Monitoring alerts 14 days before any expiration.
Threat intelligence feeds Blocklist data ingested by AdGuard Home filtering engine Varies by feed Only MIT, BSD, Apache 2.0, CC0, CC-BY, and GPL-licensed feeds are used. All CC-BY-NC feeds are explicitly excluded. Feed license compliance is reviewed before any new feed is added.

Enterprise customers requiring a formal Software Bill of Materials (SBOM) for vendor assessment can request one via [email protected]. We maintain a current dependency inventory and can provide it in CycloneDX or SPDX format. License compliance documentation is available for the on-premise appliance deployment specifically, where distribution obligations apply to GPL-licensed components.

04 — Responsible disclosure

Found something? We want
to hear from you.

Security research is a public good. If you've identified a potential vulnerability in the Nantevo platform, resolver infrastructure, authentication architecture, credential system, or any associated service, the process below explains exactly what to do and what to expect from us.

Responsible disclosure process

For security researchers and evaluators

01

Contact us privately at [email protected] with a description of the issue, the affected component, and any reproduction steps or proof-of-concept you have available. PGP encryption is available on request — ask for the public key in your initial email.

02

Receive acknowledgment within 24 hours. We read every security report personally and will confirm receipt and assign a tracking reference within one business day, typically same day.

03

Receive a timeline within 72 hours. After initial triage we'll provide an assessment of severity and an estimated timeline for investigation and remediation. We'll keep you updated as the investigation proceeds.

04

Coordinate public disclosure. We ask that researchers allow us a reasonable remediation window before public disclosure. We'll work with you on timing, credit, and the disclosure format. We do not pursue legal action against good-faith researchers following this process.

[email protected]
PGP key: available on request
Response SLA: <24 hours · typically same day
Our commitments to researchers
Acknowledgment within 24 hours — no automated responses
Clear remediation timeline provided within 72 hours
Credit in the disclosure unless researcher prefers anonymity
No legal action against good-faith security research
Coordinated disclosure timing — we don't rush you
Direct communication with the engineering team — no PR layer
Scope — in scope for disclosure
nginx virtual host and location block configuration
Reverse proxy / authentication layer
DNS resolver infrastructure and configuration
RoCi analysis pipeline and API surface
Dashboard and client portal
MDM profile generation and credential binding
TLS certificate management and rotation
Out of scope
Denial of service attacks against production infrastructure
Social engineering targeting Nantevo staff or customers
Physical security of hosting facilities
Issues in third-party software without Nantevo-specific impact
05 — Penetration testing

Enterprise vendor assessments
that require third-party testing.

Organizations that require independent penetration testing of Nantevo's infrastructure as part of their vendor risk assessment process can coordinate directly with the engineering team. We take these seriously and will work to accommodate assessment requirements without disrupting other customers.

Coordinated assessment process

For enterprise design partners and procurement evaluations

Contact [email protected] to initiate a penetration testing coordination conversation. We'll work through scope, timing, rules of engagement, and any specific methodology requirements your security team has.

We ask that assessments be coordinated in advance — primarily to ensure that test traffic is clearly distinguished from real customer traffic, that other customers' service quality is protected, and that our team has context to distinguish legitimate testing from an actual incident during the assessment window.

Assessment reports are treated as confidential security documents. We ask for a copy of the final report to drive remediation and will provide a remediation timeline within a reasonable window after report delivery.

What to include in your request
Your organization and the vendor assessment context
Proposed scope — which components and surfaces to assess
Preferred testing window and estimated duration
Name of the testing firm if using a third party
Any specific methodology requirements (OWASP, PTES, CREST, etc.)
On-premise appliance testing

Organizations deploying the on-premise virtual appliance can conduct internal penetration testing of the appliance within their own infrastructure without coordination — it's your network and your appliance. We ask only that you share findings so we can improve the hardening of future releases.

Penetration testing coordination is available to enterprise inquiry contacts and design partner organizations. Contact [email protected] to start the conversation.

06 — Compliance & certifications

Framework alignment today.
Certifications on the roadmap.

Nantevo's architecture was designed to align with the security frameworks that govern enterprise DNS security purchasing decisions. Formal certifications are on the roadmap as the platform scales toward general availability.

Aligned NSA / CISA PDNS Guidance (2021) Architecture aligned with joint NSA and CISA advisory recommending Protective DNS. Counters malware's pervasive use of DNS for command and control through encrypted, authenticated, filtered resolution.
Aligned NIST SP 800-81r3 (2026) NIST's current Secure DNS Deployment guidance. DoH enforced on all enrolled devices per the guidance's recommendation of encrypted DNS transport to maintain resolution integrity and confidentiality.
Aligned NIST SP 800-207 — Zero Trust Architecture Every query authenticated — no network implicitly trusted. Per NIST ZTA, no request proceeds without verified identity; SP 800-81r3 explicitly identifies the DNS service as a policy enforcement point.
Aligned CISA Protective DNS Resolver (2022) Architecture modeled on the CISA federal PDNS resolver design — the same foundational approach deployed for federal agency protection, validated at enterprise scale by two and a half years of production operation.
Aligned RFC 8484 — DNS-over-HTTPS Full compliance with the DoH specification. All enrolled devices use RFC 8484-compliant encrypted DNS transport. TLS 1.3. HTTPS POST and GET request format support.
In review SOC 2 Type II SOC 2 audit scoping is underway. Target completion aligns with general availability launch. Existing production operation, documented maintenance procedures, and configurable logging policies form the audit foundation.
Roadmap FedRAMP Authorization Targeted for government and defense contractor customers. FedRAMP authorization requires SOC 2 as a prerequisite. On the post-GA roadmap alongside dedicated government region infrastructure.
Roadmap ISO 27001 Information security management system certification. Targeted for enterprise customers in regulated industries — financial services, healthcare, and legal sectors where ISO 27001 is a standard vendor requirement.

Organizations requiring compliance documentation — framework mapping narratives, architecture questionnaires, or vendor assessment forms — should contact [email protected]. We have documentation ready for most standard enterprise security questionnaire formats and will work to complete custom forms within a reasonable turnaround.

Questions not answered here?

Reach us directly at [email protected] — or start with a demo and we'll walk through any security architecture questions live with the engineering team.