10 immutable laws of security, 25 years later
Law #1: If a bad guy can persuade you to run his program on your computer, it's not your computer anymore
“It's an unfortunate fact of computer science: when a computer program runs, it will do what it's programmed to do, even if it's programmed to be harmful. When you choose to run a program, you are making a decision to turn over control of your computer to it. Once a program is running, it can do anything, up to the limits of what you yourself can do on the computer… That's why it's important to never run, or even download, a program from an untrusted source—and by "source," I mean the person who wrote it, not the person who gave it to you. There's a nice analogy between running a program and eating a sandwich. If a stranger walked up to you and handed you a sandwich, would you eat it? Probably not. How about if your best friend gave you a sandwich? Maybe you would, maybe you wouldn't—it depends on whether she made it or found it lying in the street. Apply the same critical thought to a program that you would to a sandwich, and you'll usually be safe.” - 10 Immutable Laws of Security
It is both fascinating and scary to realize that this 25-year-old warning is even more relevant today than it was at the time when Microsoft published it. Gone are the days when we could even hope to enumerate what’s running and where. It’s not just EXE anymore; it’s a long list of different options:
Each of these examples introduce a new surface for untrusted code, and in each case, we are generally doing an okay job assessing the security of the platforms (Chrome, VSCode, Slack, Salesforce, etc.) but a terrible job controlling the growing number of plugins (extensions, integrations, bots, or agents) running on top of them. Moreover, a growing number of software supply chain attacks means that even trusted developers may unknowingly run malicious code. To borrow Microsoft’s analogy: it’s like buying a sandwich from a top restaurant you trust, only to get poisoned because the meat supplier, halfway across the country, maliciously tampered with the ingredients. You didn’t eat a stranger’s sandwich, but you still got burned because trust now extends deep into the supply chain.
Law #2: If a bad guy can alter the operating system on your computer, it's not your computer anymore
“In the end, an operating system is just a series of ones and zeroes that, when interpreted by the processor, cause the computer to do certain things. Change the ones and zeroes, and it will do something different. Where are the ones and zeroes stored? Why, on the computer, right along with everything else! They're just files, and if other people who use the computer are permitted to change those files, it's "game over"...” - 10 Immutable Laws of Security
In today’s cloud-first world, the definition of “operating system” has expanded far beyond the physical machine. While traditional OS tampering still exists, attackers now more often try to subvert the control planes that manage fleets of virtual machines or containers. In cloud environments, compromise of the control plane or metadata APIs can often have the same effect as altering the OS directly: total takeover of workloads.
This law is more relevant than ever because modern infrastructure is built on layers of trust that are rarely verified. Infrastructure-as-code can accidentally propagate malicious changes at scale, CI/CD pipelines often have write access to system configurations, and misconfigured agents can be exploited to gain system-level privileges. Even endpoint agents meant to provide security (like EDRs) become targets - if an attacker disables or tampers with them, downstream telemetry and enforcement fail. Protecting the "OS" has become more complex and distributed, but doing it is as critical as before.
Law #3: If a bad guy has unrestricted physical access to your computer, it's not your computer anymore
“...Always make sure that a computer is physically protected in a way that's consistent with its value—and remember that the value of a computer includes not only the value of the hardware itself, but the value of the data on it, and the value of the access to your network that a bad guy could gain. At a minimum, business-critical computers like domain controllers, database servers, and print/file servers should always be in a locked room that only people charged with administration and maintenance can access. But you may want to consider protecting other computers as well, and potentially using additional protective measures…” - 10 Immutable Laws of Security
The meaning of this law and the context around it have evolved quite a bit since the start of the pandemic and the rise of hybrid work. Laptops today are scattered across homes, airports, and coworking spaces, and even though more and more companies are pushing for a return to office, from what I’ve seen, many employees bring their computers with them (though I am definitely biased working in tech).
I am seeing two schools of thought when it comes to this problem. One school of thought still treats laptops as critical assets to be protected: hardened with EDR, full-disk encryption, secure boot, MDM enforcement, and remote wipe capabilities. For this cohort of CISOs, physical access remains a serious risk. On the other hand, a growing number of security leaders treat endpoints as disposable and untrusted by default. These organizations shift critical controls up the stack, to the browser, SaaS layer, or secure access edge, and add identity controls/SSO/MFA all around. They assume laptops will be lost, stolen, or compromised, and instead focus on controlling access, isolating sessions, and making sure that nothing valuable is stored on the device. Both philosophies agree that once someone has unrestricted physical access to the computer, they get to own it; the divergence is in whether that matters.
Law #4: If you allow a bad guy to upload programs to your website, it's not your website any more
“This is basically Law #1 in reverse… Although this scenario is a danger anytime you allow strangers to connect to your computer, websites are involved in the overwhelming majority of these cases. Many people who operate websites are too hospitable for their own good, and allow visitors to upload programs to the site and run them…If you run a website, you need to limit what visitors can do. You should only allow a program on your site if you wrote it yourself, or if you trust the developer who wrote it. But that may not be enough. If your website is one of several hosted on a shared server, you need to be extra careful.” - 10 Immutable Laws of Security
The fundamental truth of this law still holds: if an attacker can upload programs to your website, they can own it. However, unlike in 2000, many of the worst-case scenarios, like arbitrary file uploads or direct code execution on web servers, are now better mitigated. Modern web frameworks often come with built-in protections, and serverless architectures, alongside WAFs, reduce the likelihood of the kinds of breaches that were common two and a half decades ago. We’ve also made progress in dev hygiene, with security checkers and CI pipelines flagging unsafe patterns before they ship. All that said, while a lot of the problems of the past no longer apply, there are plenty of new risks that do.
Modern web threats stem less from a single attacker uploading malware and more from complex supply chain pathways: malicious open-source packages, poisoned build artifacts, vulnerable third-party SDKs, and unvalidated CI/CD workflows. In multi-tenant environments, one compromised tenant can still affect others if isolation boundaries aren’t strict, while in serverless platforms, poor permission scoping can allow attacker-controlled inputs to execute sensitive workflows. We've made progress hardening infrastructure, but the surface area has exploded beyond what it was twenty-five years ago.
Law #5: Weak passwords trump strong security
“The purpose of having a logon process is to establish who you are. Once the operating system knows who you are, it can grant or deny requests for system resources appropriately. If a bad guy learns your password, he can log on as you… Always use a password—it's amazing how many accounts have blank passwords. And choose a complex one. Don't use your dog's name, your anniversary date, or the name of the local football team. And don't use the word "password"! Pick a password that has a mix of upper- and lower-case letters, number, punctuation marks, and so forth. Make it as long as possible. And change it often… Finally, consider using something stronger than passwords to identify yourself to the system. Windows 2000, for instance, supports the use of smart cards, which significantly strengthens the identity checking the system can perform. You may also want to consider biometric products like fingerprint and retina scanners…” - 10 Immutable Laws of Security
I am quite sure that to those who, like myself, have spent less than two decades in security, reading this will feel very unsettling. Think about it: twenty-five years ago, Microsoft was asking people to set strong passwords and warning that the word "password” can’t be used as a password. Fast forward to today, and 46% of people are
still more likely to choose an easy-to-remember password than a secure one, while the
top five most common passwords are 123456, 123456789, 12345678, password (sorry, Microsoft), and qwerty123.
Some things have changed since the early 2000s. For example, as of 2024, Microsoft's recommendation to frequently change the password is
no longer considered a best practice, and the narrative has generally shifted from “use strong passwords” to “go passwordless”. At the same time, much has remained the same:
smart cards are still very much around (though we are now hoping we can get people to adopt passkeys), and “consider biometric products like fingerprint and retina scanners” continues to be good advice. The tl;dr is that weak passwords continue to trump strong security.
Law #6: A computer is only as secure as the administrator is trustworthy
“Every computer must have an administrator: someone who can install software, configure the operating system, add and manage user accounts, establish security policies, and handle all the other management tasks associated with keeping a computer up and running. By definition, these tasks require that he have control over the computer. This puts the administrator in a position of unequalled power... If you have an untrustworthy administrator, you have absolutely no security… When hiring a system administrator, recognize the position of trust that administrators occupy, and only hire people who warrant that trust. Call his references, and ask them about his previous work record, especially with regard to any security incidents at previous employers. If appropriate for your organization, you may also consider taking a step that banks and other security-conscious companies do, and require that your administrators pass a complete background check at hiring time, and at periodic intervals afterward. Whatever criteria you select, apply them across the board. Don't give anyone administrative privileges on your network unless they've been vetted – and this includes temporary employees and contractors, too.” - 10 Immutable Laws of Security
When Microsoft first published its immutable laws of security, it had to specifically call out background checks for system administrators as a security measure. Today, background checks that were once limited to “banks and other security-conscious companies” have become a common practice virtually everywhere. What hasn’t changed, however, is the assumption that trust, once granted, is permanent. Periodic re-screening of privileged users is still a largely theoretical concept since most organizations continue to assume that anyone who was trustworthy at the moment they got hired will remain that way indefinitely, even as personal circumstances and access levels evolve. It is not surprising that
insider risk is at all times high.
As with everything else, we’ve been making some good progress overall, and fewer companies are using shared admin credentials now than they were before. And yet, that is still more common than most people realize. Another best practice that hasn’t been adopted as widely as we’d like is the separation of administrative and day-to-day accounts. Many administrators continue to use their privileged accounts for regular work like checking email and browsing the internet, dramatically increasing the risk of compromise. While solutions like privileged access management and just-in-time access exist, cultural inertia and convenience tend to override security hygiene.
The very definition of an “admin” has changed, too. In the past, access was managed centrally by the IT team, but today, more and more of it is being done by different business units. Administrative privileges are scattered all over - across cloud platforms, SaaS tools, CI/CD pipelines, and identity providers, and few organizations have a good grasp of who can do what in their environment. We are getting better at RBAC enforcement and audit logging, but gaining clear visibility into who actually holds effective administrative power at any moment remains hard, in part because most SaaS vendors simply don’t provide this level of controls.
Law #7: Encrypted data is only as secure as the decryption key
“Suppose you installed the biggest, strongest, most secure lock in the world on your front door, but you put the key under the front door mat. It wouldn't really matter how strong the lock is, would it? The critical factor would be the poor way the key was protected, because if a burglar could find it, he'd have everything he needed to open the lock. Encrypted data works the same way—no matter how strong the crypto algorithm is, the data is only as safe as the key that can decrypt it… Whenever possible, use offline storage for keys. If the key is a word or phrase, memorize it. If not, export it to a floppy disk, make a backup copy, and store the copies in separate, secure locations.” - 10 Immutable Laws of Security
The “floppy disk” comment aside (I bet nearly half of my readers need to google what a floppy disk even is), unsurprisingly, the law #7 also remains valid. While encryption is now widely adopted across storage, transit, and even memory in some cases, the hard part has always been the keys, not the math. Modern cloud platforms encrypt data by default, but if you store your keys or allow access to them in the same environment (e.g., via overly permissive IAM roles or exposed metadata APIs), an attacker can potentially decrypt the data after compromising the right credentials. What’s changed since this law was first written is the scale: keys are now everywhere, managed by cloud KMSs, embedded in CI/CD secrets, handled by SaaS tools, and even hardcoded into source code repositories. The entire category of secrets scanning and non-human identity tools has emerged to tackle this problem, and we’re just starting to scratch the surface.
Microsoft’s metaphor still holds: it doesn’t matter how secure the lock is if the key is under the doormat. Practices like hardcoding secrets, leaving access tokens in CI logs, or storing unprotected credentials in cloud storage remain pretty common. Ultimately, if key management isn’t treated as a first-class problem, encryption leads to a false sense of security (when the key leaks, the data might as well be plaintext). Post-quantum encryption continues to try securing data against future quantum computers, but its benefits are moot if today's keys are still mishandled or exposed through poor operational practices. At least for the time being, we keep getting breached because of mishandled secrets, and not because of supercomputers.
Law #8: An out of date virus scanner is only marginally better than no virus scanner at all
“Virus scanners work by comparing the data on your computer against a collection of virus "signatures". Each signature is characteristic of a particular virus, and when the scanner finds data in a file, email, or elsewhere that matches the signature, it concludes that it's found a virus. However, a virus scanner can only scan for the viruses it knows about. It's vital that you keep your virus scanner's signature file up to date, as new viruses are created every day… Virtually every maker of anti-virus software provides a way to get free updated signature files from their website. In fact, many have "push" services, in which they'll send notification every time a new signature file is released. Use these services. Also, keep the virus scanner itself—that is, the scanning software—updated as well. Virus writers periodically develop new techniques that require that the scanners change how they do their work.” - 10 Immutable Laws of Security
Twenty-five years ago, when Microsoft was working on its immutable laws, security was pretty much about securing the endpoints with an antivirus, and securing networks with firewalls (I know it’s an oversimplification, but not an unfair one). A lot has changed since then, and an average enterprise today has anywhere between 30 and 100 security tools, depending on which reports you choose to read. The reason why it matters is that while the law #8 specifically talks about virus scanners, it does very much apply to every single product in the company’s environment today.
I discussed this problem at length two years ago in a blog titled “
Tools alone won't save us but if we have tools - why don't we at least use them?”. In that article, I explained the following:
“Most enterprise security teams have all the tools they need to successfully strengthen their environment. What’s lacking is the operationalization of these tools - making sure that they are properly configured, testing that they work as intended, and verifying that findings from each of the tools are being acted upon at scale. It’s too common to hear stories about companies paying a lot of money for a solution, say a data loss prevention (DLP) tool, only to realize that 30% of detections have been disabled, or security teams ignore their vulnerability reports because they don’t have enough resources to patch vulnerabilities and upgrade their infrastructure.
One of the first people who raised the topic of making the most of the tools security teams already have was Phil Venables, who
wrote a great blog about security controls back in 2019. In 2022, Jeremiah Groisman posted a
question on Twitter that sparked a solid discussion: “In your experience, when security controls should have stopped a breach, but didn’t… is it usually because the control is ineffective or was the control misconfigured/ignored?”. In March 2023, Phil Venables again published a post
titled “Fighting Security Entropy”, putting forward the idea that “Adopting a control reliability engineering mindset by continuous control monitoring is essential to counter the inevitable decay of control effectiveness”. Two weeks later, David Spark, the producer of the CISO Series, Geoff Belknap, CISO, LinkedIn, and Kenneth Foster, VP of IT governance, risk, and compliance at FLEETCOR, had a
great discussion around Jeremiah's tweet and this problem at large.”
When the security team is deploying a new tool, it’s the only time when the customer will benefit from everything the solution has to offer. From that point onward, the control quality will start to degrade: while the vendor will continue to ship new features, add more coverage, and launch new capabilities, a lot of it will be disabled by default and buried in marketing announcements, too deep for anyone to see. Security teams can barely find enough time to keep up with alerts, let alone to make sure that every product is configured to maximize its value. This was true 25 years ago with antivirus, and it is even more true today.
Law #9: Absolute anonymity isn't practical, in real life or on the Web
“All human interaction involves exchanging data of some kind. If someone weaves enough of that data together, they can identify you. Think about all the information that a person can glean in just a short conversation with you… It doesn't take long for someone to collect enough information to figure out who you are. If you crave absolute anonymity, your best bet is to live in a cave and shun all human contact… The same thing is true of the Internet. If you visit a website, the owner can, if he's sufficiently motivated, find out who you are. After all, the ones and zeroes that make up the Web session have to be able to find their way to the right place, and that place is your computer. There are a lot of measures you can take to disguise the bits, and the more of them you use, the more thoroughly the bits will be disguised… All of these make it more difficult to determine who you are, but none of them make it impossible… Does this mean that privacy on the Web is a lost cause? Not at all. What it means is that the best way to protect your privacy on the Internet is the same as the way you protect your privacy in normal life—through your behavior… But if it's complete and total anonymity you want, better start looking for that cave.” - 10 Immutable Laws of Security
When this law was written, privacy concerns were largely hypothetical for most users - social media hadn't yet taken over daily life (remember that Facebook started 4 years later), smartphones weren’t tracking everything (iPhone was first released 7 years after the immutable laws were published), and surveillance capitalism was still emerging. Since then, the world has embraced a trade many security enthusiasts didn’t predict: exchanging personal data for convenience, free services, and personalized content. Platforms like Facebook, Instagram, TikTok, and Google built entire economies around behavioral profiling, ad targeting, and data monetization. While tools for anonymity and privacy have improved (VPNs, Tor, encrypted messaging, browser hardening, etc.), they remain niche, often clunky, and used by a loud but tiny minority. For the vast majority of people, privacy has become a cost of benefiting from digital life.
I think Microsoft’s law #9 still stands, but with two important caveats. The first one is the simple fact that anonymity has been de-prioritized by both consumers and tech companies, at least in the US (it is different in Europe). The second is that it is no longer reasonable to tell people that they can protect their privacy online by simply “behaving” a certain way. The very moment people get out of their house, everything is being recorded - every step, every transaction, every interaction. Everything is logged, fed into data warehouses, and analyzed to provide more tailored shopping recommendations, to push tailored content, etc. Even as privacy regulations push for more control and transparency, they’re often undermined by complex consent flows, dark patterns, and weak enforcement. Few users truly understand how much data is collected or how it can be correlated across devices and services, but it looks like even fewer truly care.
Law #10: Technology is not a panacea
The last of the ten immutable laws of security is so important that I will provide it without shortening the way I did with the previous nine. It goes as follows.
“Technology can do some amazing things. Recent years have seen the development of ever-cheaper and more powerful hardware, software that harnesses the hardware to open new vistas for computer users, as well as advancements in cryptography and other sciences. It's tempting to believe that technology can deliver a risk-free world, if we just work hard enough. However, this is simply not realistic.
Perfect security requires a level of perfection that simply doesn't exist, and in fact isn't likely to ever exist. This is true for software as well as virtually all fields of human interest. Software development is an imperfect science, and all software has bugs. Some of them can be exploited to cause security breaches. That's just a fact of life. But even if software could be made perfect, it wouldn't solve the problem entirely. Most attacks involve, to one degree or another, some manipulation of human nature—this is usually referred to as social engineering. Raise the cost and difficulty of attacking security technology, and bad guys will respond by shifting their focus away from the technology and toward the human being at the console. It's vital that you understand your role in maintaining solid security, or you could become the chink in your own systems' armor.
The solution is to recognize two essential points. First, security consists of both technology and policy—that is, it's the combination of the technology and how it's used that ultimately determines how secure your systems are. Second, security is journey, not a destination—it isn't a problem that can be "solved" once and for all; it's a constant series of moves and countermoves between the good guys and the bad guys. The key is to ensure that you have good security awareness and exercise sound judgment. There are resources available to help you do this. The Microsoft Security website, for instance, has hundreds of white papers, best practices guides, checklists and tools, and we're developing more all the time. Combine great technology with sound judgment, and you'll have rock-solid security.” - 10 Immutable Laws of Security
It feels truly odd to read this and to realize that these words aren’t from some Black Hat talk which happened last year, or some thought leadership piece from an outspoken CISO; this is an excerpt from an article published 25 (!) years ago. These words make it perfectly clear that we knew perfectly well what we needed to do back in 2000, as well as we do today.
This law is the most enduring, and also the most ignored. Security vendors continue to promise that the next platform, the next AI detection model, the next agentic framework, or the next zero trust architecture will finally “solve” security, but the truth remains: technology can reduce risk, but it cannot eliminate it. Every new control introduces new complexity, new misconfigurations, and new blind spots, and every security failure ultimately exploits that complexity, whether it's an attacker chaining together subtle weaknesses or a team misusing the tool they thought would protect them. Perfect security is a fantasy because perfect software, perfect configuration, and perfect behavior don't exist. Just over half a year ago, I published a piece titled “
There are only two sources of security issues: software bugs and configuration mistakes”. Add to that the problem of social engineering, which I didn’t cover in my blog, and we’ll get the unholy triad that is the cause of all breaches - the past, the present, and most definitely the future.
The problem is that many organizations still try to "buy" their way to security instead of building it into their culture, systems, and operations, hoping that technology can be the substitute for solid process, accountability, and awareness. I don’t know if it even needs to be said, but no product can compensate for poor access controls, lack of inventory, untrained staff, or broken response workflows. The most expensive XDR won't help if no one's watching the alerts, and the best IAM system won’t reduce risk if people are overpermissioned. The real work of security lies in setting boundaries, enforcing consequences, asking hard questions, and doing it every single day.
What has changed is that security has become a board-level issue, and yet
the urge for silver bullets persists. AI is the latest candidate: vendors say it will stop threats, replace analysts, and close the talent gap. That may very well be true, but attackers also use AI, and the playing field is constantly moving, which means that the only durable advantage is not smarter tools, but more disciplined thinking. Security is not a product; it’s a practice. Technology helps, but judgment, process, and ownership still make the difference between a resilient organization and a breached one. That was the case twenty-five years ago, and I don’t doubt it will be the case another twenty-five years from now.
they once again prefer to pay lawyer instead of having decent security.
