Introducing Ephemeral Identities for Zero-Trust Automation

Open your device list. How many of those entries are actually alive? If you're running CI/CD pipelines, automated backups, or any kind of machine-to-machine automation, you probably have dozens of ghost devices haunting your organization. GitHub Actions runners that lived for five minutes. Jenkins agents from last month. That one-off script someone ran and forgot about.
‍

These aren't just clutter, they're a security nightmare. Every forgotten device is a credential that shouldn't exist, an attack surface you don't remember creating, and another entry eating into your device limit.

The root problem? The identity lifecycle is completely disconnected from the task lifecycle. Your GitHub Actions runner spins up, does its job in five minutes, and disappears. But its Border0 device identity? That sticks around forever, unless you write cleanup scripts. And let's be honest, nobody enjoys writing cleanup scripts.

‍

Why Static Service Accounts Are Scary

Traditional approaches to this problem don't work. Manual cleanup? Good luck keeping up with hundreds of ephemeral workloads. Periodic audits? By the time you audit, the damage might be done. Even credential rotation just shrinks the window of opportunity. it doesn't solve the fundamental issue that credentials exist when they're not needed.
‍

In our previous posts, we've shown you how to give GitHub Actions a real identity instead of wrestling with IP allowlists. Your runners in GitHub's cloud can securely connect to your private databases and servers, with granular, application-level policies and full audit trails. But if that identity persists forever, you're still accumulating risk with every pipeline run.
‍

What if these machine identities could clean up after themselves? What if they existed only when needed and vanished automatically when done?

‍

Enter the --ephemeral Flag

Today we're introducing a dead simple solution: the --ephemeral flag for the Border0 client.

Here's how it works: When you start a Border0 client with --ephemeral, it registers as a new device just like normal. It authenticates, connects to your resources, does its work. But when it disconnects, a 5-minute timer starts. If it doesn't reconnect, the device and its identity are automatically purged from your organization. No cleanup scripts. No manual intervention. No ghosts.

For new installations

sudo border0 node install --start-vpn --ephemeral --token from:file:/path/to/token

‍

For existing installations  

sudo border0 node start --home-dir $HOME --start-vpn --ephemeral

‍

One flag. That's it. Your device list stays clean, your security posture stays tight, and you never hit device limits from zombie automation.

‍

Real-World Magic: Self-Destructing CI/CD Pipelines

This is the killer use case. Your GitHub Actions workflow spins up in GitHub's infrastructure, registers with Border0 using --ephemeral, and suddenly has secure access to your private resources, no firewall rules, no IP allowlists. It connects to your database (with just the read permissions it needs), runs tests against your staging server, and completes. Five minutes later, that runner's identity is gone. No lingering credentials. No cleanup required. And you've got a complete audit trail of exactly what it accessed and when.
‍

Here's what it looks like in practice:

name: Deploy with Ephemeral Border0 Device
on: [push]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Install and Start Border0
        env:
          BORDER0_TOKEN: ${{ secrets.BORDER0_CLIENT_TOKEN }}
        run: |
          sudo curl -L https://download.border0.com/linux_amd64/border0 -o /usr/local/bin/border0
          sudo chmod +x /usr/local/bin/border0
          echo "$BORDER0_TOKEN" > /tmp/border0.token
          sudo border0 node install --ephemeral --start-vpn --token from:file:/tmp/border0.token
          
      - name: Access Private Resources
        run: |
          mysql --host=mysql-server -D production -e "SELECT * FROM orders;"
          ssh user@internal-server "deploy.sh"

‍

One-Shot Automation

Think beyond CI/CD. Any automation that needs temporary access benefits:
‍

• Nightly backups: Cron job on your utility server wakes up, authenticates with ephemeral identity, securely backs up your cloud database (with only the permissions it needs), disappears

• Auto-scaling: New instances grab config with temporary identities that vanish after bootstrap

• Terraform provisioning: Temporary test VMs get ephemeral identities that die with terraform destroy

This is zero-trust automation done right. Security isn't bolted on, it's baked into the lifecycle. Your automation can reach private resources wherever they live, with precise access controls and complete visibility, all without permanent credentials floating around.

‍

The 80/20 Rule in Action

At Border0, we obsess over the last 20% that makes everything just work. Device cleanup is one of those unglamorous problems that nobody wants to solve but everyone suffers from. You could write scripts to clean up devices. You could manually prune your device list. You could implement complex rotation schemes.
‍

Or you could just add --ephemeral and let us handle it.
‍

This is what we mean when we say we do the hard work so you don't have to. It's a simple flag that solves a complex problem. No more device limit headaches. No more security debt from forgotten identities. No more ghosts in your infrastructure.

‍

Exorcise Your Ghosts Today

The ephemeral devices feature is available now for all Border0 users. Check out our  documentation for details, or if you're new to Border0, sign up for our free community edition and see how much cleaner your device list can be.

Because the best credential is the one that doesn't exist when you don't need it. 🎃

‍