GrapheneOS has a list of security requirements for future devices based on the status quo of the current generation devices we support:
https://grapheneos.org/faq#future-devices
Other than security patches, hardware memory tagging support is easily the most important feature on this list.
GrapheneOS is the first platform using ARM hardware memory tagging in production. This provides a form of memory safety for memory unsafe languages. It has a high random chance of catching most memory corruption and always catches certain major classes of memory corruption bugs.
Hardware memory tagging is such an important feature that we highly prioritized integrating it and enabling it by default once it became available.
Snapdragon 8 Gen 3 still lacks memory tagging support so Snapdragon devices likely won't meet our requirements until 2025 or later.
Qualcomm usually does a good job with security but they've dropped the ball on this. Even MediaTek recently released an SoC platform with MTE support.
Other than memory tagging, the requirements on our list can be met by a theoretical security-focused Snapdragon-based device.
Samsung has committed to providing 7 years of security support with 7 generations of major OS updates, which matches current Pixels. We previously limited our update requirement to 4 years to enable using Snapdragon. We'll be raising it to 5 years for phones and 7 for tablets.
We'll be adding reset attack mitigation via memory zeroing for firmware-based boot modes to our list of requirements once it's shipped for Pixels in a few months. We recently filed upstream reports about vulnerabilities in firmware being exploited on stock OS Pixels due to this.
GrapheneOS implements memory zeroing in the kernel page and slab allocators which does zero most OS memory on reboot, but we don't consider that adequate. It's possible for the OS to lock up or crash in a way that it doesn't get an opportunity to zero. The firmware should do it.
A few of the existing features on our list of hardware requirements were implemented based on our proposals. We filed a bug about earlier Pixel generations using an overly truncated verified boot key hash, and we proposed pinning-based hardware attestation support (attest keys).
We have to do a lot of device-specific hardening work such as fixing or working around bugs uncovered by security features like hardened_malloc and MTE. We also do research into hardware/firmware issues despite not making it. Pixels have benefited from us regularly filing issues.