When Low-End Devices Become Attack Surfaces: Axiom OS — A Kernel-Level Provenance Solution for Digital Equity and Cyber Safety in India

India's smartphone market has expanded to over 700 million users, yet the majority of new users — students, rural residents, low-income adults, and first-time device owners — access digital services on sub-$200 devices running end-of-life (EOL) Android versions with zero official security patches. This paper presents an empirical, data-driven study connecting smartphone price fragmentation, Android EOL fragmentation, unpatched CVE exposure, and rising cybercrime against both children and adults with low-end devices in India. Using four publicly available datasets — Flipkart device listings (1,836 records), Statcounter Android market share data, the NVD 2023 CVE database (31,157 vulnerabilities), and NCRB official crime data (2017–2022) — we find that 52.8% of listed Indian smartphones are priced below $200, 39.7% of Indian Android users operate on unpatched or near-EOL systems, and cybercrime against children rose 2,208% over five years. These three findings converge on a single structural problem: the at-risk population uses hardware that existing security solutions were never designed to support. We propose Axiom OS — a bare-metal x86_64 kernel written in Rust — as a proof-of-concept structural solution. Axiom OS is architecturally superior to Linux IMA in three specific, measurable domains: (1) verification granularity — Axiom verifies on every read, whereas Linux IMA verifies only at load/exec time, leaving in-memory modification attacks invisible; (2) trust boundary — Axiom's provenance check is the read path itself, with no trusted userspace layer that can be compromised by a ring-0 exploit, whereas IMA runs within the Linux LSM framework; and (3) hash algorithm — Axiom uses BLAKE3 (2.8 cycles/byte, 256-bit security) versus IMA's SHA-256 (18.4 cycles/byte), making per-read verification computationally viable. IMPORTANT CONTEXT: Axiom OS is a research prototype — not a production system. It is deliberately minimal (no network stack, no GUI, no multi-core support, limited syscalls). Direct boot-time and RAM comparisons with Windows Defender or full Linux distributions are therefore not apples-to-apples comparisons and should not be interpreted as such. The correct interpretation is: even at this minimal prototype stage, Axiom OS already enforces per-read cryptographic provenance — something no general-purpose OS currently does — with measured RDTSC benchmarks of 574,302 cycles/op (BLAKE3) and 2,389,648 cycles/op (VFS read+verify). As features are added toward a production-capable kernel, overhead will increase; however, given that BLAKE3 verification adds only 0.797ms per read at 3GHz even in this prototype, there is a substantial performance budget available for feature additions before resource usage approaches Windows Defender or full Linux levels.