- Six servers checked on every port, over IPv4 and IPv6. From the internet, each now answers only on secure web.
- Account isolation proven live: two test accounts on the real network could not reach each other, our servers, or a real subscriber's device.
- Code review of the identity engine found four issues (one high, two medium, one low). All four were fixed, tested and live the same morning, plus one small follow-up the same day.
- Two server weaknesses found (password login allowed, software versions visible). Both fixed the same night.
- No secrets in 1,739 commits of source-code history.
- Nothing found was ever used against us. The server logs show no successful break-in.
At a glance
Every issue found was fixed
Each green block is one issue: found, fixed and checked on the live system.
The work, in order
- Servers stop revealing what they run
Software labels removed from every server and published API maps switched off.
- Source code scanned for secrets
All 1,739 commits checked. Nothing live found, and the scanner now runs on every change.
- Control server reviewed
Access rules, join keys and internal services all passed. Administrator login switched to keys only.
- Every port on every server scanned
IPv4 and IPv6. Only the services each server needs answer. The city exits switched to keys-only login.
- Identity engine code fixed and live
All four code review findings fixed, with 31 new tests. Security headers added to every Atlas web address.
- Administrator login taken off the internet
Now reachable only through Atlas's own private network.
- Account isolation proven live
Two test accounts on the real network couldn't reach each other, our servers or a subscriber's device.
- Final follow-up fix
One rare address format now refused. Nothing left open.
What we checked
| Check | How | Coverage |
|---|---|---|
| Open network ports | Scan of every TCP port (1–65,535) from outside each server | All 6 servers, IPv4 and IPv6 |
| Common UDP services | Scan of the 100 most-used UDP ports | All 5 city exits |
| Administrator login | Which sign-in methods each server accepts, and from where | All 6 servers |
| Public DNS | Whether the control server answers DNS from the internet | Control server, IPv4 and IPv6 |
| What servers reveal about themselves | Software labels in replies, published API maps, security headers | Every public Atlas web address |
| Private network access rules | Review of the access policy and every join key ever issued | Control server |
| Account isolation | Two throwaway test accounts on the live network, each trying to reach everything else | Live network |
| Identity engine code | AI-assisted security review of the code, each finding checked by hand | Identity engine (accounts, devices, network access) |
| Leaked secrets | Open-source secret scanner across the full history, every match reviewed by hand | All 1,739 commits |
What we found and fixed
| Severity | What we found | What we did | Status |
|---|---|---|---|
| High | When setting up home access for an edge unit, the identity engine accepted any network range, not just a home one. An account could have named a range belonging to Atlas or to someone else. | Only private home-sized ranges are accepted now. Atlas's own ranges are refused, one account per range, and only for an account that has its own edge unit. 31 new tests. | Fixed, live 5 Oct |
| Medium | A change to the private network's access rules was checked against the old rules, not the new ones, before going live. | The new rules are now checked before they replace the live ones. A failed check changes nothing. | Fixed, live 5 Oct |
| Medium | Removing an edge or home device from an account left it on the private network. | Removing a device now removes it from the network too. | Fixed, live 5 Oct |
| Low | A per-account limit could be slightly exceeded by many requests sent at the same moment. | The limit is now reserved in one step. A test with 40 simultaneous requests stops exactly at the limit. | Fixed, live 5 Oct |
| Low | Follow-up from the high finding: one rare address format passed the new check but couldn't be used by the network. | That format is now refused with a plain message. Test added. | Fixed, live 5 Oct |
| Medium | Administrator login accepted passwords on five of six servers, so anyone could keep guessing. The control server logged 15,391 failed attempts, ordinary internet background noise. None succeeded. | All six servers now accept only cryptographic keys, and new servers are built that way. Then we went further: administrator login is no longer reachable from the public internet at all, only through Atlas's own private network. | Fixed 5 Oct |
| Low | Servers named their software and versions in replies, and two services published a full map of their endpoints. | Software labels removed on every server, API maps switched off, and standard security headers added to every Atlas web address. | Fixed 4–5 Oct |
Every fix was backed up before the change, verified on the live system after it, and recorded in our internal change log.
What passed with nothing to fix
| Check | Result |
|---|---|
| Open ports | Pass Only the services each server needs answer. The other 65,532 TCP ports stay silent. IPv6 matches IPv4 exactly, so there's no side door. |
| Device connection port | Pass Each city server answers only to genuine Atlas devices and is invisible to a scanner. |
| Internal services | Pass DNS, management and admin pages on the control server can't be reached from outside. |
| Access rules | Pass Every account's devices sit in their own group and can reach only each other. |
| Join keys | Pass Every join key ever issued has expired. There are no standing keys. |
| Secrets in code | Pass None of the 53 possible matches is a live Layer9i secret. They are examples in third-party documentation, public labels and test data. The scanner now runs on every change, and we confirmed it catches a planted test secret. |
One historical item, for completeness: in September an Android signing key was found in an earlier public copy of the app. It was retired and replaced at the time, and every Android release since has been signed with a new key.
Isolation, proven on the live network
Separation between accounts is the core promise, so we tested it on the real network rather than on paper. We created two throwaway test accounts, each with its own server, set up exactly as a new subscriber's would be.
| From a test account, trying to reach… | Result |
|---|---|
| The other test account | Blocked |
| Atlas's control server and a city server | Blocked |
| The administrator's computer | Blocked |
| A real subscriber's edge unit | Blocked |
Each test account could see only itself. The administrator's own computer couldn't reach a subscriber's device either: Atlas staff have no path into customer devices. Afterwards the test accounts, their access groups and both test servers were deleted.
Protecting the source code
- Two-factor sign-in is on for the code host account, and only the founder has access.
- An encrypted offline copy of all source code and its history is kept, and a test restore succeeded.
- The foundation code is tagged by date from the first app onward, as a record of authorship.
Next steps
| Item | Why | Status |
|---|---|---|
| Independent third-party penetration test | Outside confirmation of everything above | Before public launch |
| Extend the code review to the apps and the older dashboard service | Same depth of review across all code | Planned |
| Retire the older dashboard service and an unused network listener | Less to defend, even though both were already closed off | Done 6 Oct |
| Repeat this review | After every new server, and every quarter | Ongoing |
Questions
Server addresses, scan output and the detailed change records are kept internally and are available under NDA.