Why security hardening matters#
A single misconfigured VM or leaked API key can expose your infrastructure. Following these steps reduces attack surface and limits damage if credentials are compromised. Each section includes practical steps you can apply today.
1. SSH key authentication#
Password-based SSH is vulnerable to brute force. Use SSH keys and disable password authentication.
- Generate an SSH key pair if you don’t have one:
ssh-keygen -t ed25519 -C "your@email.com" - When creating a VM in the console, paste your public key or select one from your account. Edge injects it into
~/.ssh/authorized_keys. - After first login, disable password auth: edit
/etc/ssh/sshd_config, setPasswordAuthentication no, then restartsshd.
2. Firewall rules (security groups)#
Edge uses security groups to control inbound and outbound traffic to VMs. Restrict access to only what your application needs: for example, ports 80/443 for web and port 22 for SSH from your IP only.
- In the console, go to Compute → Security Groups.
- Create a group with a sensible name (e.g. “web-server”).
- Add inbound rules: allow TCP 22 from your IP (or a VPN/jump-host IP), TCP 80/443 from 0.0.0.0/0 if the VM serves web traffic.
- Attach the security group to your VM(s).
Avoid opening 0.0.0.0/0 for SSH unless necessary. Use edge compute security-groups in the CLI to manage rules.
3. Two-factor authentication for your Edge account#
Enable 2FA on your Edge account. If your password is ever leaked, an attacker still needs your authenticator device.
- Go to Settings → Security in the console.
- Click Enable 2FA.
- Scan the QR code with an authenticator app (Google Authenticator, Authy, 1Password, etc.).
- Enter the verification code to confirm. Store recovery codes in a secure place.
4. API key management#
API keys grant full account access. Rotate them periodically and scope them when possible.
- Rotation: Create a new key every few months or when a team member leaves. Revoke old keys in Settings → API Keys.
- Scoping: Use read-only keys for monitoring/backup workflows where write access is not needed.
- Storage: Never commit keys to version control. Use environment variables or a secrets manager.
Prefer Agent Access Codes for AI agents and automation. They have scoped permissions and budget limits, which reduces the blast radius if one is compromised.
5. SSL/TLS#
When you use Edge CDN with a custom domain, SSL/TLS is handled automatically. Edge provisions and renews certificates for you. Make sure your domain is added to the CDN deployment and that DNS points to Edge. HTTPS is then enabled by default.
For direct VM access (e.g. SSH), connections use your client’s SSH key exchange. For web apps on VMs, put the CDN in front so traffic is encrypted end-to-end via Edge’s edge SSL.
6. DNS security#
DNSSEC adds cryptographic signing to DNS records, preventing spoofing and redirect attacks. DNSSEC support on Edge DNS is coming soon, and we’ll announce it when it’s available.
In the meantime, use strong, unique passwords for your domain registrar and Edge account, and enable 2FA on both where possible.
7. Keep VMs updated#
Unpatched systems are a common attack vector. Schedule regular updates for your VM OS and application dependencies.
On Ubuntu/Debian:
- Run
sudo apt update && sudo apt upgrade -y. - Reboot if the kernel was updated.
Consider automating with cron or a configuration management tool. Edge’s base images are updated regularly, so recreate VMs periodically to get the latest base.
8. Agent access codes with limited permissions#
If you use AI agents or coding assistants to manage Edge infrastructure, do not give them your account API key. Use Agent Access Codes instead: scoped credentials with time limits and budget caps.
- Go to Account → Agent Access in the console.
- Create a new code. Restrict products (e.g. only CDN and Compute, not billing).
- Set a budget cap so the agent cannot exceed a spend limit.
- Set an expiry date. Rotate codes when projects end.
This limits damage if an agent’s context is leaked or misused. See Agent access codes for details.
9. Protect public forms and endpoints with Edge Shield#
Firewalls protect your VM, but your public forms (login, signup, contact, checkout) are open to the world by design. That’s where credential stuffing, form spam, and fake account waves come in. Edge Shield closes that gap for free, without showing real visitors a CAPTCHA.
- Create a widget in the console under Shield. You get a public sitekey and a server-side secret.
- Add the script tag and an
edge-shielddiv to each form you want protected. - Validate the submitted token from your server with one call to
siteverify. Tokens are signed, single-use and expire in five minutes. - Act on the 1–100 humanity score: block low scores on sensitive routes, or route verified agents to your API instead.
See the full walkthrough in Bot protection with Edge Shield.
Keep learning
Security4 min read
Securing login & signup flows
Credential stuffing and fake account waves are the two most common attacks on any site with a login form. Here's how to stop both without adding friction for the humans you actually want.
Background4 min read
Edge network security
The network edge is where your infrastructure first meets the open internet, which makes it the best place to stop attacks. Here's what securing the edge involves.
Security3 min read
Bot protection with Edge Shield
Stop form spam, credential stuffing and fake signups without ever showing a human a puzzle. Two lines on the page, one HTTP call on the server. Free forever.