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:
- Security and operational incidents (immediate public disclosure required)
- Internal issues (no public disclosure required)
- 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
- 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
- Disclose fast: Operational incidents disclosed same-day with precise timestamps
- Explain technically: Clear root cause analysis without jargon
- Credit our users: Acknowledge users who report issues (Telegram, support channels)
- Clarify architecture: Distinguish between decentralized network and centralized services
- Reassure privacy: Explicitly state what privacy guarantees remain intact
- Share fixes: Detail remediation steps and prevention measures
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
- When users first experienced issues
- When Nym team became aware
- When service was restored
Root cause
Technical explanation of what went wrong, including:
- For security issues: Attack vector and how it occurred
- 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
- 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
- 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.