I started my career designing and running Check Point FW-1, Cisco PIX and Nokia firewall estates. Two and a half decades later I’m designing IAM policies, security groups and cloud-native WAF rules — different tooling entirely, but the underlying discipline hasn’t changed nearly as much as people assume.
The first principle that carries straight across is least privilege, deliberately applied. A firewall ruleset built on "allow what’s needed, deny everything else, and review it regularly" produces the same outcome as an IAM policy built the same way — the difference is just the granularity and the speed at which mistakes propagate.
The second is that segmentation still matters, it’s just drawn differently. On-premise, that boundary was a DMZ and a VLAN. In the cloud, it’s account boundaries, VPC design and security group scoping — but the underlying question is identical: what can reach what, and does it actually need to?
The third, and the one most often forgotten, is that a rule you can’t explain is a rule you should remove. I spent years rationalising firewall rulesets that had accumulated a decade of "just in case" entries nobody could justify. Cloud IAM policies rot the same way, usually faster, because provisioning a new permission is a one-line change instead of a change request.
What is genuinely different is the blast radius of a mistake, and the speed at which infrastructure changes. That’s exactly why the automation and pipeline discipline matters as much as the architecture itself — a misconfigured security group deployed through a reviewed, version-controlled pipeline is a very different risk to one changed by hand at 2am.