The appearance of PamStealer, a newly identified infostealer targeting macOS, is a real warning. So is the broader pattern behind it: security researchers report increasing development activity for macOS-targeting infostealers, and they characterize PamStealer as distinct from previously known macOS malware. That matters because it tells us this is not a one-off nuisance. Attackers are investing in the Mac ecosystem, and the old assumption that relative obscurity is protection no longer holds.
But a genuine threat does not make every sweeping remedy wise. The resolution before us asks whether operating system vendors should implement mandatory hardware-level security verification for all third-party applications. The key words are mandatory, hardware-level, and all. A proposal this broad should be judged not only by the fear that produced it, but by the institutional order it would create.
The strongest case for the resolution deserves to be stated fairly. Existing software defenses are porous. Code signing, app review, sandboxing, and user warnings have not eliminated infostealers. End users are badly equipped to distinguish a legitimate installer from a malicious one. Security is a collective problem, and malware imposes costs far beyond the individual victim, from credential theft to business compromise to erosion of trust in the platform itself. From that perspective, a hardware-rooted verification system sounds like the next logical layer: move trust lower in the stack, make verification harder to evade, and stop malicious software before it executes.
That argument has force. History is not a sermon against all centralization. Durable institutions often arise because dispersed decision-making fails under pressure. Banking supervision, food inspection, and aviation safety all emerged from the recognition that some hazards are too systemic to leave entirely to private caution. If the case for mandatory verification were merely that operating systems should offer stronger secure enclaves, better notarization, and tighter default permissions, it would be easy to agree.
But that is not this resolution. This resolution would give operating system vendors mandatory hardware-level control over whether every third-party application may run. That is a much larger constitutional fact of the digital economy, even if no written constitution directly governs it. It would convert platform stewardship into platform sovereignty.
We have seen this pattern before. Whenever a gatekeeper acquires the power to approve all entry into a system, the rationale begins with safety and ends with dependency. In earlier centuries, licensing regimes for presses were justified by disorder and fraud; in modern markets, control points in telecommunications, payment networks, and app distribution have repeatedly expanded from quality assurance into market management. The lesson is not that every gatekeeper is tyrannical. It is that concentrated control rarely remains limited to its founding purpose.
A mandatory hardware verification regime would create a single point of failure in at least three senses. First, it would create a technical choke point. If attackers compromise the verification chain, the compromise scales across the ecosystem. Second, it would create an economic choke point. Developers would have to satisfy the vendor's approval rules, timelines, and compliance costs before software could function at all. Third, it would create a political choke point. Governments would know exactly where to apply pressure when they want applications blocked, modified, delayed, or surveilled.
Advocates of the resolution reply, reasonably, that every security architecture has choke points, and that the point is to raise the cost of attack. True enough. But the relevant question is not whether any system can be attacked. It is whether the proposed system fails gracefully, or whether it fails systemically. A universal hardware-verification mandate is brittle because it unifies trust too completely. One defect in design, one abuse of discretion, one mistaken revocation, one policy drift by the vendor, and the damage propagates widely.
Nor does hardware-level verification solve the whole malware problem suggested by PamStealer. Infostealers thrive not only through unsigned binaries, but through social engineering, stolen developer credentials, supply-chain compromise, malicious updates, and abuse of legitimate permissions. Security history is full of examples where defenders hardened one layer only to discover that attackers simply moved to the adjacent one. Mandatory verification might reduce some classes of malware, and that concession is important. But the resolution promises a universal answer to a problem that is adaptive, not static.
The cost side is also too often dismissed as mere friction. It is not. Requiring all third-party applications to pass hardware-level security verification would burden independent developers, open-source maintainers, enterprise internal tools, academic software, legacy applications, and experimental products very differently from large commercial publishers. The burden would not be shared evenly. The very actors least able to absorb compliance delay and integration expense would face the highest relative cost. Historically, such systems do not only screen out bad actors. They entrench incumbents.
That is why the analogy to app store monopolization is more than rhetoric. If an operating system vendor controls the hardware root of trust and makes that control mandatory for all software execution, then software distribution may remain formally open while becoming substantively conditional. A right that exists only after approval from the platform is not a robust right. It is a revocable license.
The wiser course is not passivity, and opponents of the resolution should not pretend otherwise. The rise in macOS malware development calls for stronger notarization, faster revocation of known malicious certificates, better isolation of sensitive data, stricter default entitlements, transparent permission prompts, optional hardware-backed verification modes for high-risk environments, and clearer avenues for independent security auditing. Enterprises, schools, and governments may well choose mandatory hardware-rooted controls on managed devices. That is a targeted use of authority, not a universal redesign of software freedom.
What they should not do is normalize the principle that operating system vendors must approve, at the hardware level, all third-party applications for all users. Once built, such power will not remain confined to malware screening. It will shape competition, speech, repair, research, and the practical meaning of ownership over personal computers.
PamStealer is a warning, but not the one maximalists imagine. The warning is that security threats evolve quickly, and institutions must respond without surrendering the pluralism that makes technical ecosystems resilient. Good constitutional orders, and good computing orders, do not assume that safety requires a sovereign with final say over every act. They disperse power, preserve exceptions, and build layered defenses that can be improved without making one private authority the master key to all software.
The record is clear enough. In moments of anxiety, centralization always presents itself as efficiency. Later generations discover the bill. Operating system vendors should harden their platforms aggressively. They should not be given, or give themselves, mandatory hardware-level veto power over every third-party application.