The standard framing of phishing is that it is a people problem — a failure of user awareness that better training can fix. This framing is wrong, or at least dangerously incomplete. Phishing is also an infrastructure problem, and the infrastructure fixes are more reliable than training because they do not depend on every person making the right decision every single time.
A phishing email that successfully harvests credentials is not the end of the attack. It is the beginning. What happens next — how far the attacker gets, how much damage they do, how long it takes to detect them — is determined almost entirely by the infrastructure they land in. That is the part you can engineer.
What a Phishing Attack Is Actually Trying to Accomplish
Most phishing campaigns targeting businesses are not trying to install malware directly. They are trying to obtain valid credentials or session tokens that allow the attacker to authenticate as a legitimate user. Once they have those credentials, they do not need exploits or malware — they simply log in.
This matters because it means the attack bypasses most perimeter security controls. Firewalls, IDS systems, and antivirus are largely irrelevant once an attacker is authenticating with valid credentials. The only controls that remain effective are those that govern what authenticated users can actually do.
The Email Infrastructure Layer
The first infrastructure defence against phishing is at the email layer, and it is largely a DNS configuration problem. Three records — SPF, DKIM, and DMARC — form the authentication framework for email. Together, they allow receiving mail servers to verify that an email claiming to be from your domain was actually sent by your infrastructure, and to reject or quarantine messages that fail that verification.
SPF (Sender Policy Framework) specifies which IP addresses are authorised to send email on behalf of your domain. An email sent from an unauthorised IP fails SPF.
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to outgoing email that the receiving server can verify against a public key in your DNS. A forged email cannot carry a valid DKIM signature.
DMARC (Domain-based Message Authentication, Reporting and Conformance) ties SPF and DKIM together and specifies what to do with messages that fail: monitor, quarantine, or reject. A DMARC policy of p=reject tells receiving mail servers to drop unauthenticated email claiming to be from your domain outright.
Many organisations have SPF records but no DMARC policy, or a DMARC policy set to p=none (monitoring only). This means spoofed emails impersonating your domain still reach recipients. Configuring DMARC to p=reject eliminates an entire category of impersonation attacks against your customers and partners.
What Stolen Credentials Can Do Depends on Your Architecture
If a phishing attack successfully obtains a set of credentials, the damage it can do is bounded by what those credentials can access. In a poorly segmented environment with broad permissions, a single compromised account can access email, file shares, internal systems, and administrative interfaces. In a well-architected environment, the same credentials might access a single application with limited data exposure.
The infrastructure controls that contain credential compromise are:
Multi-factor authentication on all remote access. MFA does not prevent credential theft, but it makes stolen credentials useless for remote access without the second factor. An attacker with a valid password but no MFA token cannot authenticate. This is the single highest-leverage control against phishing-based attacks and is straightforward to implement on SSH, VPN, web applications, and cloud consoles.
Least-privilege access control. Every user, service account, and application should have access to exactly the resources it needs and nothing more. An email account compromise should not provide access to database servers. An application service account should not have the ability to read configuration files for other applications. Implementing this requires deliberate access control design, not just accepting defaults.
Network segmentation. Even if an attacker authenticates successfully, network-level controls determine where they can go from there. A user whose credentials are compromised should not be able to reach internal server subnets directly. A compromised workstation should not be able to initiate connections to database servers. Firewall rules between segments enforce these boundaries even when credential-based controls have been bypassed.
Short session lifetimes and anomaly detection. Sessions that persist for days or weeks give attackers a large window to operate. Shorter session lifetimes and re-authentication requirements for sensitive actions reduce that window. Logging all authentication events and alerting on anomalies — logins from new locations, unusual hours, atypical data access patterns — creates detection opportunities even when the attacker has valid credentials.
The SSH and Admin Access Problem
Phishing attacks targeting technical staff often aim for SSH keys, API credentials, or admin panel access rather than general user accounts. A developer or administrator whose credentials are compromised can provide access to infrastructure that user credentials would never reach.
The infrastructure controls for privileged access are stricter than for general user accounts. SSH access to production servers should require key-based authentication, with keys stored in a secrets manager rather than on developer workstations. Admin consoles should be accessible only from known IP ranges, or through a hardened bastion host. All privileged sessions should be logged, and the logs should be stored in a location that a compromised admin account cannot modify or delete.
Why Training Alone Is Not Enough
User awareness training reduces phishing click rates. It does not eliminate them. In large organisations running simulated phishing campaigns, click rates of 5–10% are considered good outcomes. That means that in an organisation of 200 people, 10–20 people will click on a well-crafted phishing email even after training.
Infrastructure controls that assume some fraction of users will always be successfully phished are more robust than controls that assume perfect user behaviour. The goal is not to make users infallible — it is to ensure that a successful phish results in the smallest possible blast radius.
Auditing Your Current Exposure
A phishing-resilient infrastructure requires a combination of email authentication configuration, MFA enforcement, access control design, and network segmentation. If you are not certain which of these controls you have in place and whether they are correctly configured, the answer is to find out before an attacker does.
At Solvanta, security audits cover all of these layers: we check your email authentication records, review your access control policies, map your network segmentation, and verify your logging and alerting coverage. The output is a risk-ranked list of findings with specific remediation steps. Get in touch to schedule an audit.