Your domains are valuable assets that require enterprise-level security protection.
They deserve the same level of protection that banks use for financial data.
At Nerve.io, I've built our security architecture from the ground up to address the unique challenges of domain management while maintaining transparency about our approach and limitations.
This article provides a comprehensive overview of our current security measures, explains how we protect against various threat scenarios, and outlines our roadmap for future enhancements as we expand from read-only operations to full create, update, and delete capabilities.
Current Security Architecture
The Unscoped Credentials Problem
Before diving into our security architecture, it's important to understand the fundamental problem Nerve.io is solving.
All registrars that provide API functionality offer unscoped credentials. This means that when you give someone access to your registrar account through your API credentials, they have complete control over all your domains.
This creates a MASSIVE security risk, especially as we enter the AI and Agent growth curve.
Here are some likely scenarios where unscoped credentials can lead to disaster:
AI/LLM Integration Risks:
- Registrants sharing registrar API keys with AI assistants for domain management tasks
- LLMs potentially storing or exposing credentials in conversation logs
- AI agents making unauthorized changes across entire domain portfolios
- Credentials being shared across multiple AI services without proper scoping
Third-Party Developer Risks:
- Inexperienced developers using insecure coding practices
- API keys being hardcoded in source code or configuration files
- Credentials being shared across development teams without proper access controls
- Lack of audit trails for third-party access to domain management
Agent Automation Risks:
- Automated scripts with full domain access making unintended changes
- No granular permissions for different types of operations
- Single point of failure – one compromised credential affects all domains
- Difficulty in revoking access without affecting legitimate operations
This is exactly why I built Nerve.io's scoped access system – to prevent these scenarios from becoming reality.
While registrars could theoretically implement their own scoped credential systems, this would require every registrar to independently develop and maintain such features.
Given their current priorities and the fragmented nature of the domain industry, this is unlikely to happen anytime soon.
Even if they did, users would still need to manage separate scoped credentials across multiple registrars, losing the unified management experience that Nerve.io provides.
Google Cloud KMS Encryption
Our primary defense mechanism centers around Google Cloud Key Management Service (KMS).
When users provide their registrar API credentials, these sensitive details are immediately encrypted using AES-256 encryption before being stored in our database.
The encryption process works as follows:
- User enters credentials through our secure web interface
- Credentials are sent to Google Cloud KMS for encryption
- Only the encrypted ciphertext is stored in our database
- Plaintext credentials exist in memory only during the brief encryption process
- Google KMS handles all key management and rotation automatically
This approach ensures that even if our database is compromised, attackers cannot access the actual API keys without also compromising our Google Cloud infrastructure and the specific KMS keys used for encryption.
Limited Access Keys (LAKs)
Instead of exposing master registrar credentials, we implement a Limited Access Key system that provides temporary, scoped access to specific domains and operations.
Each LAK includes multiple layers of access control and restrictions designed to minimize security risks:
- Scoped Access: Keys are limited to specific domains and operations
- Time-Limited: Automatic expiration to limit exposure windows
- Network Controls: Optional access restrictions for additional security
- Instant Management: Keys can be disabled immediately if needed
The LAK system follows the principle of least privilege, ensuring that each key has only the minimum permissions necessary for its intended use.
Comprehensive Audit Logging
Every action taken through our system is logged in our database, providing complete visibility for you and our monitors into system usage.
Our audit logs capture comprehensive information about system usage, including:
- User activities and access patterns
- System operations and their outcomes
- Network and access information
- Timestamps for all activities
This logging system allows users to monitor their account activity and provides administrators with tools to detect and investigate suspicious behavior.
Enterprise Security Infrastructure
We've implemented enterprise-grade security infrastructure that provides additional layers of protection at the application and server levels.
This infrastructure includes:
- Advanced Threat Protection: Multiple layers of protection against web-based attacks
- Automated Security Scanning: Regular scans for vulnerabilities and suspicious activity
- Enhanced Authentication: Multi-factor verification for administrative access
- Session Security: Protection against unauthorized session access
- Security Headers: HTTP security headers for enhanced protection
- Reputation Monitoring: Automatic checking against security intelligence feeds
This infrastructure adds enterprise-grade security monitoring to our existing application-level protections.
To be clear, this isn't some hastily assembled system running on a budget cloud server. We've invested in proper enterprise infrastructure with the security considerations that domain management requires.
Security Limitations and Transparency
The Insider Threat Challenge
I must be transparent about a fundamental security limitation that exists in any service handling sensitive credentials: insider threats.
This represents a significant challenge that no purely technical solution can completely eliminate, as authorized personnel always have some level of access to systems.
This same insider threat exists at every registrar you currently use. When you register domain names at any registrar, their employees have access to your domain management capabilities.
What sets Nerve.io apart is our commitment to transparency and accountability in how we handle this responsibility.
My reputation in the domain industry depends on maintaining the trust of the community I've served for over two decades, and this personal accountability serves as an important safeguard.
Current Read-Only Operations
Nerve.io's current implementation is intentionally limited to read-only operations for security reasons.
This means:
- Users can only view domain name information
- No domain transfers or deletions are possible
- No DNS modifications can be made
- No registrar account changes are allowed
This limitation significantly reduces the potential damage from compromised access while I develop more sophisticated security controls.
We will communicate with users about security updates and new features, allowing them to opt in or out of these communications while maintaining our security-first approach.
Database Security Considerations
While we use Google KMS for encryption, the encrypted data is still stored in our database.
This means:
- Database compromise could expose encrypted credentials
- Decryption would still require Google Cloud access
- Our service account credentials are stored securely in our infrastructure
- Our backup systems maintain the same encryption standards as our primary systems
What If We're Breached?
While we implement multiple layers of security, it's important to be transparent about what happens if those defenses are somehow compromised. Here's our detailed incident response and recovery plan:
Immediate Response (Within 1 Hour)
Credential Rotation: If a breach is detected, we immediately:
- Rotate all affected Google Cloud KMS keys
- Generate new encryption keys for all impacted users
- Update service account credentials across all systems
System Isolation: Compromised systems are immediately:
- Isolated from production networks
- Taken offline for forensic analysis
- Replaced with clean backups from secure storage
User Notification (Within 4 Hours)
Priority Communication: Affected users receive:
- Direct email notification with breach details
- Timeline of the incident and our response
- Specific actions they need to take
- Contact information for immediate support
Transparent Reporting: We provide:
- What data may have been exposed
- What systems were affected
- Steps we've taken to contain the breach
- Recommendations for additional security measures
Recovery Support (Ongoing)
Dedicated Support Team: During recovery, users get:
- Priority technical assistance for any issues
- Help with credential rotation at their registrars
- Guidance on additional security measures
Prevention of Future Incidents
Post-Incident Improvements: After any breach, we:
- Conduct comprehensive security audits
- Implement additional safeguards based on lessons learned
- Update our security practices and documentation
Future Security Enhancements
As Nerve.io prepares to implement create, update, and delete operations, I'm planning several security improvements to address current limitations.
External Audit Logging
I plan to implement immutable audit logging that sends security events to external services I don't control.
This system would:
- Send signed audit logs to third-party monitoring services
- Use HMAC signatures to prevent tampering
- Provide independent verification of system activity
- Alert users to suspicious administrative actions
Per-User KMS Keys
Instead of using a single KMS key for all users, I'm considering a system where each user gets their own encryption key.
This approach would:
- Isolate user credentials from each other
- Require individual KMS permissions for each user
- Prevent cross-user credential access
- Provide better access control granularity
Automated Key Rotation Policy
Our automated key rotation policy follows industry best practices for credential lifecycle management.
This ensures:
- Regular Rotation: Keys are rotated at appropriate intervals to minimize exposure windows
- Enhanced Security: Regular rotation reduces the impact of compromised credentials
- Seamless Experience: The rotation process is automated and transparent
- Proactive Protection: Compromised credentials have limited useful lifetime
Regular Penetration Testing
We conduct regular penetration testing (pentests) of our entire system to proactively identify and fix security vulnerabilities before they can be exploited.
What is a Pentest?
A penetration test is a controlled, authorized attempt to hack into our systems using the same techniques and tools that real attackers would use. Our security team (or authorized third-party experts) systematically tries to find weaknesses in our:
- API endpoints and authentication systems
- Database security and access controls
- Network infrastructure and firewalls
- Application code and business logic
- User access and permission systems
Our Pentest Process:
- Regular Testing: We perform comprehensive security assessments on a regular basis
- Real-World Scenarios: Tests simulate actual attack scenarios that could target domain management systems
- Rapid Remediation: Any vulnerabilities found are addressed promptly
- Continuous Improvement: Each assessment helps us strengthen our security posture
I believe in "security through transparency." Regular pentesting is just one way I demonstrate my commitment to protecting your domain assets.
Multi-Person Approval Workflows
For high-risk operations like registering, updating and deleting domain names, I'm designing approval systems that require multiple authorized individuals.
These workflows would:
- Require approval from designated administrators
- Implement time-delayed execution for sensitive actions
- Provide notification systems for pending approvals
- Create audit trails for approval decisions
Code Integrity Verification
I'm exploring code signing and verification systems to detect unauthorized modifications.
This would include:
- Digital signatures for all application code
- Runtime verification of code integrity
- Alert systems for detected modifications
- Independent code review processes
Third-Party Security Audits
I plan to engage independent security firms to audit our systems and provide third-party validation.
These audits would:
- Review our security architecture
- Test our encryption implementations
- Validate our access control systems
- Provide public security reports
Best Practices for Users
While we implement technical security measures, users also play a crucial role in maintaining security.
The account security practices we recommend are similar to what your registrars require – strong passwords, two-factor authentication, and regular access reviews. However, where registrars stop, we go much further with our advanced key management, comprehensive monitoring, and detailed reporting capabilities.
Account Security
- Use strong, unique passwords for your Nerve.io account
- Enable two-factor authentication when available
- Regularly review your account access and permissions
- Monitor your audit logs for unusual activity
Key Management
- Create LAKs with minimal necessary permissions
- Set appropriate expiration dates for all keys
- Revoke unused or compromised keys immediately
- Use IP restrictions when possible for additional security
Monitoring and Reporting
- Regularly review your domain access logs
- Report any suspicious activity immediately
- Monitor your registrar accounts for unauthorized changes
- Keep contact information updated for security notifications
Shared Responsibility Model
Security at Nerve.io operates on a shared responsibility model.
Nerve.io's Responsibilities
- Implementing and maintaining encryption systems
- Providing secure infrastructure and monitoring
- Developing and testing security controls
- Responding to security incidents and vulnerabilities
- Maintaining transparent security practices
User Responsibilities
- Protecting account credentials and access
- Managing limited access keys appropriately
- Monitoring account activity and reporting issues
- Following security best practices and recommendations
- Keeping systems and browsers updated
Compliance and Standards
I'm building our security architecture to meet various compliance requirements.
Industry Compliance
Our security practices and controls are designed to meet industry standards for data protection and security, with regular independent verification of our security practices.
Data Protection Standards
Our systems implement comprehensive data protection and privacy controls, including detailed logging of data access and modifications to ensure compliance with global privacy regulations.
Incident Response and Monitoring
Real-Time Security Monitoring
I have implemented continuous monitoring systems that detect and respond to security threats.
Nerve.io's monitoring includes:
- Continuous system activity monitoring
- Automated detection of unusual patterns
- Alert systems for security events
- System performance and health tracking
Incident Response Procedures
When security incidents are detected, we follow established response procedures:
- Immediate containment of threats
- Investigation and analysis of incidents
- User notification and communication
- Post-incident review and improvement
Business Continuity
Our security systems are designed to maintain service availability while protecting user assets.
This includes:
- Redundant security monitoring systems
- Backup and recovery procedures
- Graceful degradation during security events
- Communication protocols for users
Security Through Transparency
Security at Nerve.io represents a comprehensive approach to protecting domain assets while maintaining transparency about our capabilities and limitations.
Our current architecture provides strong protection against external threats through Google KMS encryption, limited access keys, comprehensive audit logging, and WPMU DEV Defender Pro integration.
However, I acknowledge the fundamental challenge of insider threats and am actively developing additional safeguards as I expand our operational capabilities.
The key to our security approach is transparency, continuous improvement, and a commitment to building trust through demonstrated security practices rather than simply claiming to be secure.
As we move toward implementing create, update, and delete operations, we will continue to enhance our security architecture while maintaining the same level of transparency and user protection that defines our current approach.