What I Learned from 15 Years in the Trenches

A common example is MFA. Requiring MFA for every action may look secure, but it can create user friction and operational noise. A better approach is to apply stronger authentication where the risk is higher, such as privileged access, production systems, payment approvals, customer data, and cloud consoles.

Security is not about making every action equally hard. It is about protecting the most valuable actions with proportionate controls, while keeping normal work usable, monitored, and recoverable.

A classic example is password rotation. Many enterprises used to force password changes every 90 days, and some stricter environments used 30 days. This looked secure on paper, but often led users to create predictable passwords, reuse patterns, or store passwords unsafely.

A better approach is to require strong passphrases, block known compromised passwords, use MFA, monitor suspicious logins, and reset passwords when compromise is suspected. A control that creates bad user behavior is not strong security.

A common example is MFA for admin access. The policy may say all privileged access requires MFA, and the system may show that MFA is enabled.

Verification means checking the evidence: review the MFA policy scope, confirm all admin groups are included, check for excluded accounts, test a privileged login, and review sign-in logs to prove MFA was enforced. A control only becomes mature when it can be proven to work.

An online payment system is a good example. Confidentiality matters, but integrity matters more. The highest risk is someone changing the payee, amount, approval status, or transaction record.

So the strongest controls should focus on approval workflow, segregation of duty, transaction validation, audit logs, reconciliation, and fraud monitoring. The security priority must follow what the system is meant to protect.

Production support access is a good example. If access is too restricted, engineers cannot investigate incidents quickly. If access is too broad, too many people hold standing production privileges.

A better design gives read-only access by default, requires approval for privileged actions, grants temporary access only when needed, and logs all activity. Access control should let people do their work safely, not force a choice between speed and security.

Deleting a production database backup is a clear example. SSO and MFA prove who the engineer is, but they do not prove the engineer should be allowed to delete a critical backup.

The system must check authorization through role, environment, approval, and policy. It must also record the action in audit logs, including who acted, what allowed it, what was deleted, and when it happened.

Cloud storage is a common example. A system may have good architecture, encryption, SSO, and logging. But if a storage bucket is accidentally made public, the configuration defeats the design.

Permissions, keys, network rules, and admin settings must be reviewed like security controls. Bad configuration can turn a secure design into an exposed system.

Ransomware protection is a good example. A company may have email filtering, endpoint protection, MFA, network segmentation, privileged access control, and backups.

But defense in depth fails if the backups use the same admin credentials, sit on the same network, and are never tested. Each layer must be independent, monitored, and verified. Otherwise, one compromise can still take down the whole environment.

A compromised user account is a clear example. Email filtering, MFA, and endpoint protection reduce risk, but they will not stop every phishing attempt or credential theft.

Good security assumes a control may fail. The design must detect unusual logins, revoke sessions, reset credentials, review access logs, contain the account, and confirm what data was accessed. Prevention reduces the chance of compromise; response limits the damage after compromise.

A third-party API integration is a good example. It is not enough to say the vendor system is trusted. The design must define exactly which vendor application is trusted, which internal system accepts that trust, what API actions are allowed, and what scope limits apply.

The evidence must also be clear: approved OAuth scopes, certificates, source restrictions, logs, and ownership records. Trust that cannot be explained is not trust; it is an assumption.

Cloud production access is a good example. An engineer may log in through SSO, get approval in a PAM tool, assume a temporary cloud admin role, and then change a production resource.

The access path must be traceable from the engineer, to the approval ticket, to the PAM session, to the cloud role, to the exact API call, and finally to the resource changed. If the cloud log only shows “AdminRole” or “pipeline-service-account,” the trace is incomplete. You know what acted, but not clearly who requested it, who approved it, and why it was allowed.

Privileged access to a production server is a good example. A weak audit log may only say, “User accessed server.” That shows activity, but it does not explain why the access was allowed.

A better log records the user identity, privileged role, approval ticket, access policy, session ID, source device, time, command activity, and reason for access. The log should allow a reviewer to answer: who accessed production, who approved it, what permission allowed it, what they did, and whether it matched the approved purpose.

A firewall exception is a strong example. A vendor needs temporary access to support a production issue, so the team allows access from the vendor IP to an admin interface for one week.

The real risk starts when the exception has no owner, no expiry date, no ticket reference, and no review process. Months later, the rule is still active, the vendor no longer needs it, and reviewers only see a “working” firewall rule, not the original risk decision.

Exceptions are not the problem. Invisible exceptions are the problem. Every exception should have a business reason, owner, approval, scope, expiry date, and review evidence.

Browser-based SaaS access is a clear modern example. A user may open email, documents, and internal systems in the same browser where they also visit external websites. If malicious web content can run with the same authority as trusted business apps, one bad page can steal sessions, read data, or trigger actions as the user.

A safer design separates trusted and untrusted code. Use browser isolation, sandboxing, device posture checks, app control, code signing, and controlled file transfer between environments. Untrusted code should never run with the same access as trusted business applications.

Cloud production deployment is a good example. A team may say, “Only approved code can be deployed to production,” but that control is weak if approval happens in email, deployment is done manually, and evidence is scattered across different tools.

A better design makes verification simple. The CI/CD pipeline should show who approved the change, which code was deployed, which tests passed, which security checks ran, which identity performed the deployment, and what production resource changed. If the control cannot be easily checked, it will be hard to operate safely.

Using more than one edge security provider can reduce vendor concentration risk. For example, an organization may use Akamai and Imperva to avoid relying on a single provider for CDN, WAF, DDoS, bot, or API protection.

But diversity does not protect the application by itself. If the origin is still reachable directly, or if policies, logs, failover, and ownership are inconsistent, attackers may bypass the edge or exploit the weakest setup. Provider diversity only helps when the architecture enforces isolation, blocks origin bypass, aligns security policies, and tests failover in practice.

Temporary cloud admin access is a good example. An engineer may be granted elevated access to troubleshoot a production issue. That access should be limited to the required role, approved ticket, target account, and short time window.

The risk starts when temporary access becomes permanent. Tokens stay valid, sessions remain active, emergency roles are not removed, or signed links continue working after the task is complete. Temporary access must expire automatically, support revocation, and leave audit evidence showing who used it, why, and when it ended.

Privileged cloud access is a practical modern example. A single engineer should not be able to approve their own request, assume a production admin role, disable security logging, or change critical cloud resources alone.

A safer design requires one person to request access, a separate approver to approve it, and the platform to grant a short-lived role only after approval. The system should log the requester, approver, ticket, role assumed, session duration, API actions, and resources changed. High-risk cloud actions should require independent approval, not just technical permission.