How Nym Technologies SA responds to security incidents

v1.0 as of 14 November 2025

I. Nym's commitments

Transparency in real-time: We believe privacy requires trust, and trust requires transparency. When incidents occur, whether security breaches or operational disruptions, we communicate quickly, clearly, and honestly with our community.

User above all: Every decision in our incident response process prioritizes user security and privacy.

II. Types of incidents we disclose

We classify incidents into two categories:

1. Security and operational incidents (immediate public disclosure required)
2. Internal issues (no public disclosure required)

Security and Operational Incidents (immediate disclosure)

1. Security incidents involve the potential compromise of user data, privacy, or cryptographic systems:

• User credentials, payment data, or personally identifiable information exposed or at risk
• Compromise of cryptographic keys enabling traffic decryption
• Breach of core infrastructure (authentication, payment systems, zk-nym issuance)
• Zero-day vulnerabilities actively being exploited
• Any incident requiring user action to maintain security

2. Operational incidents are service disruptions (connectivity, performance, availability):

• NymVPN connectivity problems or gateway unavailability
• API or infrastructure outages preventing connections
• Network performance degradation
• Third-party infrastructure failures affecting service

Disclosure requirement: Immediate

Note: Security incidents require immediate user action and detailed impact assessment. Operational incidents are inconvenient but don't compromise privacy.

Internal issues (no public disclosure)

Issues resolved before user impact include:

• Vulnerabilities discovered and fixed pre-production
• Operational improvements during routine maintenance
• Configuration errors caught in audits with no exploitation
• Internal security hardening

Documentation: Internal knowledge base only

III. Nym's approach to disclosure

1. Disclose fast: Operational incidents disclosed same-day with precise timestamps
2. Explain technically: Clear root cause analysis without jargon
3. Credit our users: Acknowledge users who report issues (Telegram, support channels)
4. Clarify architecture: Distinguish between decentralized network and centralized services
5. Reassure privacy: Explicitly state what privacy guarantees remain intact
6. Share fixes: Detail remediation steps and prevention measures

IV. Format for incident reports

Based on our actual practice, every incident report includes:

Headline summary

A clear description of what happened and its current status

Timeline

Precise timestamps (UTC) to explain

1. When users first experienced issues
2. When Nym team became aware
3. When service was restored

Root cause

Technical explanation of what went wrong, including:

1. For security issues: Attack vector and how it occurred
2. For operational issues: Infrastructure component that failed

Architecture context

Clarification of which systems were affected:

• Decentralized network (600+ independent nodes) and/or
• Centralized services (account management, payments, API)

Privacy impact assessment

• What user data/activity was potentially affected
• What privacy guarantees remained intact

User and community acknowledgment

Credit given to users who reported the issue

Remediation actions

• Immediate fixes deployed
• Additional resources or infrastructure changes
• Long-term prevention measures

What users should do

Including clear actions (even if it's "no action required")

V. Communication channels

How we notify users:

• Prominent banner on nym.com and in our Help Center
• Real-time updates on Discord, Telegram, and X
• Real-time status on our Status page
• Post-event blog post on our Blog (incident report series)
• In-app notifications (when possible)
• Additional email notification (if we have user emails)

We often learn about issues from our community (Discord, support tickets, Telegram, X) and we acknowledge them by name in our reports. This creates a feedback loop that helps us respond faster.

VI. Decentralized architecture disclosures

We clearly distinguish in every incident report:

• Centralized NymVPN services: Account management, payments API, etc.
• Decentralized Nym network: 600+ independent node operators running gateways and mix nodes, and doing distributed zk-nym credential issuance

Why this matters:

• API outages affect login/connection but don't compromise privacy of existing connections
• Network node issues are localized to specific operators
• We cannot control node operators (the network is designed to penalize repeatedly bad performing node operators)

Note: users need to know that infrastructure outages don't compromise the fundamental privacy architecture. Our zero-knowledge credential system means:

• Payments remain unlinkable to VPN usage
• Even if centralized API fails, privacy guarantees persist
• Multi-layer encryption remains intact

VII. Post-incident actions

Immediate (0-24 hours)

• Restore service
• Deploy emergency fixes

Short-term (1-7 days)

• Publish incident report on our Blog
• Implement monitoring improvements

Long-term (ongoing)

• Architecture improvements to prevent recurrence
• Enhanced automation for faster recovery

VIII. Vulnerability Disclosure Policy & Bug Bounty Program

Please refer to our policy and program.