Secure remote access to edge and IoT devices
You can securely access edge and IoT devices without exposing inbound ports, distributing SSH keys, or managing VPN infrastructure. With m87 (make87's command line + device runtime), devices establish an outbound QUIC tunnel (TLS 1.3 over UDP 443) — reducing attack surface while maintaining full access.
The security challenges
Remote access to edge devices typically forces a tradeoff between security and convenience. Exposing SSH or VNC to the internet creates an attack surface that requires constant hardening — fail2ban, rate limiting, CVE patches. Distributing SSH keys means managing authorized_keys across every device and tracking who has access when engineers leave. VPNs solve the exposure problem but introduce their own complexity: PKI infrastructure, long-lived network membership, and the operational burden of certificate lifecycle management. Bastion hosts centralize access but become high-value targets that require their own hardening and monitoring.
Each approach either increases attack surface or shifts operational burden elsewhere.
How outbound-only access works
The core principle is simple: the device initiates all connections. It opens an outbound QUIC tunnel to the make87 platform and keeps it alive. When you need shell access, the platform signals the device over the existing tunnel — no inbound ports, nothing for attackers to scan or probe.
Traditional: Internet → open port → device (attackable)
Outbound-only: Internet → (nothing) → device (not reachable)
Users authenticate through the make87 platform using OAuth/SSO. The device itself stores no SSH keys or user credentials — identity verification happens at the platform layer, and sessions are established on-demand through the existing tunnel. All traffic uses QUIC with TLS 1.3 encryption, and different operations (shell, exec, port forwarding) are multiplexed as separate QUIC streams over the same connection.
This means access is per-session rather than persistent. Unlike a VPN where devices remain network members indefinitely, each session is scoped and temporary. Access control lives in the platform, not in per-device configuration files.
Quick start
1) Set up the device
m87 runtime login
m87 runtime enable --now
The device authenticates and opens an outbound QUIC tunnel to UDP 443. No inbound ports required.
2) Access securely from anywhere
m87 login
m87 <device> shell
Your identity is verified. A session is established. No keys exchanged out-of-band.
What you don't have to manage
No SSH key distribution
Traditional approach:
- Generate keys
- Copy public keys to devices
- Manage
authorized_keysfiles - Rotate keys periodically
- Revoke keys when people leave
With m87: authenticate through the platform. No user keys or credentials stored on devices.
No exposed ports to harden
Traditional approach:
- Open SSH (port 22) or other services
- Configure fail2ban, rate limiting
- Monitor for brute force attempts
- Keep services patched
With m87: no inbound ports — no remotely exploitable network services.
No VPN membership lifecycle
Traditional approach:
- Provision VPN identities
- Manage certificates or keys
- Handle device joins and leaves
- Audit long-lived network access
With m87: per-session access. No persistent network membership.
Access control
User authentication
Users authenticate via the make87 platform (OAuth/SSO). No shared passwords or keys.
Device approval
New devices require approval before they're accessible:
m87 devices approve <device>
Reject unknown devices:
m87 devices reject <device>
Organization-level control
Manage device access at the organization level through the make87 platform. Add or remove team members without touching devices.
Audit and visibility
Device inventory
See all registered devices:
m87 devices list
Session activity
The make87 platform logs session activity: user ID, device ID, timestamps, and session duration.
Runtime logs
On-device, check what's happening:
m87 <device> logs
m87 <device> logs -f # follow
Hardening recommendations
Even with outbound-only access, good device hygiene matters:
Keep the OS updated
m87 <device> exec -- sudo apt update && sudo apt upgrade -y
Disable unnecessary services
If you're not using SSH locally, disable it:
m87 <device> exec -- sudo systemctl disable ssh
Use least-privilege containers
When deploying via Docker, don't run containers as root unnecessarily:
services:
app:
user: "1000:1000"
# ...
Monitor resource usage
Watch for anomalies:
m87 <device> stats
Comparison: security posture
| Concern | SSH (exposed) | VPN | Bastion | Outbound-only (m87) |
|---|---|---|---|---|
| Inbound ports | Port 22 (or custom) | UDP 500/4500 (IKEv2), UDP 51820 (WireGuard), or TCP 443 (OpenVPN) | Port 22 on bastion host | None — device initiates all connections |
| Key/cert management | authorized_keys per device, manual rotation | PKI infrastructure or PSK distribution | authorized_keys on bastion + agent forwarding config | OAuth/SSO tokens, no device-side key storage |
| Attack surface | sshd exposed to internet scans | VPN daemon + key negotiation endpoint | sshd on bastion, lateral movement risk post-auth | QUIC egress to UDP 443 only, no listening sockets |
| Brute force vectors | Password/key auth attempts against sshd | IKE/WireGuard handshake floods, credential stuffing if password-based | Same as SSH, concentrated on single host | None — no inbound authentication endpoint |
| Access revocation | Remove pubkey from each authorized_keys file | Revoke VPN cert/identity, update CRL or OCSP | Remove from bastion authorized_keys | API call removes user from org, immediate effect |
Alternatives (and tradeoffs)
SSH with exposed ports
Pros:
- Native on Linux devices; no additional daemon required
- Direct connection with well-understood security model
Cons:
- Port 22 exposed to internet scanning and brute-force attempts
- Requires fail2ban, rate limiting, and prompt CVE patching
- Key management at scale (authorized_keys distribution, rotation, revocation)
- Unusable behind CGNAT without bastion or reverse tunnel infrastructure
VPN-based access
Pros:
- Full Layer 3 network access to device subnet
- Well-audited protocols (WireGuard, IPsec)
Cons:
- PKI infrastructure or PSK distribution per device
- Long-lived network membership until explicitly revoked
- Split-tunneling decisions affect routing; misconfiguration can leak traffic
- VPN client software required on operator machines
Bastion host
Pros:
- Single ingress point for firewall rules and IDS placement
- Centralized session logging and audit trail
Cons:
- Bastion itself is a high-value target requiring hardening
- Single point of failure; downtime blocks all device access
- ProxyJump configuration required on all clients
- Still requires key management (on bastion) and patching
FAQ
Is the connection encrypted?
Yes. All traffic uses QUIC with TLS 1.3 encryption between your laptop, the make87 platform, and the device.
Who can access my devices?
Only authenticated members of your organization. You control membership through the make87 platform.
Can I revoke access immediately?
Yes. Remove a user from your organization, and they lose access to all devices. Remove a device, and no one can access it.
What if the platform is compromised?
The platform brokers connections but does not have shell access to devices or access to data on the device filesystem. Device authentication is tied to the runtime registration, and device credentials can be rotated by re-registering.
Is this compliant with [SOC2 / ISO27001 / etc.]?
Outbound-only access with centralized authentication and audit logging aligns well with most compliance frameworks. Specific compliance depends on your overall security posture, not just remote access.
Can I use this alongside existing security tools?
Yes. m87 handles access; you can still run host-based firewalls, intrusion detection, or other security tooling on devices.