Why HearthGate Was Ready for macOS Tahoe Before Tahoe Shipped

macOS 26 Tahoe changed the context around remote access in two important ways. On Apple silicon, FileVault can now be unlocked over SSH after a restart when Remote Login is enabled and a network connection is available. Separately, Apple describes the Application Firewall's block-all setting as blocking incoming connections regardless of app.

Those facts do not make Tahoe unsafe, and HearthGate does not claim to neutralize the pre-boot FileVault feature. They do make one design question impossible to ignore: if SSH must remain reachable while other network services stay sealed, which layer should express that policy?

The Application Firewall is useful for controlling incoming access to apps and services. Its block-all mode is intentionally broad. Once that mode is enabled, an app exception is no longer a narrow escape hatch for SSH.

For a remote Mac that must accept SSH while refusing direct VNC access, the network policy needs a lower-level expression. On macOS, that layer is the packet filter, pf. This is attack-surface reduction: preserve the one entry path you need, and remove the screen service as an independent network-facing door.

HearthGate does not turn Screen Sharing into a proprietary viewer service, and it does not modify the Application Firewall. VNC Lockdown writes a focused rule into Apple's packet-filter infrastructure. The rule is compact enough to inspect directly:

The first line drops inbound TCP traffic to port 5900. The next two lines permit IPv4 and IPv6 loopback traffic. In a HearthGate workflow, the VNC client reaches a local tunnel endpoint; SSH authenticates the connection first, and the Mac reaches its own Screen Sharing service through loopback at the tunnel exit.

The practical result is a smaller exposed surface. A device on the LAN cannot walk directly up to the VNC port. The user must first pass through the SSH access controls that HearthGate manages, including key policy, origin scope, limits, logging, and revocation.

Conservative hardening guidance often recommends disabling Screen Sharing entirely. The ERNW macOS 26 Tahoe Hardening Guide takes that position to minimize network attack surface, and that is a reasonable baseline when remote graphical access is not required.

HearthGate addresses a different operational need. Mac admins, homelab operators, support teams, and remote Mac mini users may need the capability. Instead of pretending the service does not exist or leaving it directly reachable, HearthGate keeps it and seals it behind authenticated SSH.

A firewall rule that disappears after a restart is a demo, not a durable control. HearthGate reapplies its named lockdown policy at boot. It also cleans up its own rule and supporting state when the app is removed, so the Mac is not left stranded behind an orphaned configuration.

The policy is deliberately scoped. HearthGate preserves the surrounding packet-filter structure and uses its own named anchors, allowing the VNC restriction to coexist with a broader Mac hardening baseline.

Tahoe did not disclose an Apple VNC vulnerability that HearthGate had secretly patched. That would be the wrong claim. The operating system clarified the firewall tradeoff: block everything at the Application Firewall, or use a policy layer capable of keeping SSH reachable while controlling the screen path separately.

That is the decision HearthGate made from its first release. Tahoe did not create the model; it made the value of the model easier to explain. The quiet conclusion is the strongest one: HearthGate got to the right layer first.

If Screen Sharing is never needed, disable it. If it is needed, ask a more exact question: should port 5900 be a network entry point, or should authenticated SSH be the only door?

HearthGate is built around the second answer. It keeps Apple Screen Sharing in the workflow, preserves familiar VNC clients, and reduces the network surface to a key-gated SSH path that can be observed, restricted, and revoked.