Cisco's SSE FDE role: 7+ years of networking, security and reproducible escalations

Picture this: a large customer has just moved the whole company’s web traffic onto a cloud proxy. The next morning, staff at one branch are stuck in an endless login loop on an internal application. The customer’s IT team blames your product; your own engineering team wants evidence before it accepts anything.

Standing between those two sides is exactly the job Cisco describes in its posting for a Forward Deployed Engineer in Secure Services Edge (SSE), listed under Duo Security.

The posting asks the FDE to take full ownership of complex escalations, keep customer expectations realistic and provide precise, reproducible technical evidence.

The reason to pay attention is the FDE label. The role was popularised by Palantir, and many people hear “FDE” and think straight away of AI or data. Cisco’s posting shows a very different variant: heavy on networking, security and incident-handling discipline.

If you are aiming for infrastructure FDE roles, reading this posting properly gives you a list of things to practise over the next few years.

Read the posting and you find three jobs

The first is customer ownership. The posting says the FDE will lead the technical relationship with a pre-assigned set of large or strategic SSE accounts. In other words, you have your own list of customers, and when they run into trouble, you are the first person they call.

The second is handling escalations, on a follow-the-sun rotation across time zones. The third is in the posting’s own wording: problems customers hit again and again must be fed back into the product and engineering roadmap as concrete requests.

All three come with demanding working conditions: the posting requires up to 50% travel, within the US and internationally, to customer offices and engineering centres. Ask for clarity on the travel and on-call schedule in the very first interview round.

The experience bar is stated plainly too: 7+ years in networking or security, with direct customer ownership.

Networking first, code second

The technical list in the posting covers DNS, routing, IPsec tunnels, TLS, SAML, SWG/web proxies and cloud networking, plus 5+ years of identity and SSO integration (SAML/OIDC, SCIM) in enterprise environments.

In an SSE product, each of these is a place where things can break: DNS and routing decide whether traffic passes through the service at all, IPsec connects branches to the cloud, TLS is where content inspection happens, and SAML handles identity.

Those requirements are all protocols and infrastructure, not programming languages. In a role like this, the most useful code is usually small scripts to diagnose and reproduce faults, like the one below:

import socket, ssl

DOMAINS = ["app.example.com", "login.example.com"]

for host in DOMAINS:
    try:
        ip = socket.gethostbyname(host)
        ctx = ssl.create_default_context()
        with socket.create_connection((host, 443), timeout=5) as s:
            with ctx.wrap_socket(s, server_hostname=host) as t:
                issuer = dict(x[0] for x in t.getpeercert()["issuer"])
        print(host, ip, "issuer:", issuer.get("organizationName"))
    except socket.gaierror as e:
        print(host, "DNS error:", e)
    except ssl.SSLError as e:
        print(host, "TLS error:", e)
    except OSError as e:
        print(host, "connection error:", e)

If the certificate issuer is the proxy’s CA rather than a public CA, you know the traffic is being decrypted for inspection. That detail alone is enough to split a login incident into two lines of investigation.

What does a clean escalation look like?

In practice, the posting’s demand for “precise, reproducible technical evidence” means logs, pcaps, configs with sensitive information redacted, and steps to reproduce the fault. Going back to the login loop at the start, a clean escalation might look like this:

Title: SAML loop at Branch B after enabling TLS inspection
Scope: Branch B only, some users affected; Branch A normal
Started: immediately after a configuration change (time and change ticket attached)
Verified:
  - Client-side pcap: the IdP site's certificate is issued by the proxy's CA
  - Disabling inspection for the IdP domain in the lab -> fault gone (repro steps attached)
Unverified:
  - Hypothesis that the session cookie is stripped at the proxy (AI suggestion from logs, not confirmed by pcap)
Attached: proxy logs, pcap, redacted config
Ask: confirm expected behaviour for the IdP domain; customer is using a temporary exception

The “Unverified” section is the one many people skip, yet it matters most. The posting allows AI to be used for log analysis but demands sound judgement, and no unverified conclusion may be passed to anyone, customer or engineering.

From the third ticket to a roadmap request

Suppose the third account on your list hits exactly the same fault. At that point, fixing it customer by customer is no longer enough. The posting asks the FDE to turn recurring patterns like this into concrete requests, and a complaint differs from a concrete request in three ways:

Product teams can put on the roadmap things with a clear scope and a clear way to test them. PostHog’s handbook describes the same principle at another company: when a customer is blocked by something only the product team can fix, the FDE hands it over to the owning team, and some teams prefer an async write-up while others want you to join their standup.

So before sending anything, ask the receiving team which format it prefers, then scope the problem yourself and write down how to test the fix.

How to prepare

Start with a small lab: two cloud VMs connected by an IPsec tunnel, a self-hosted proxy with TLS decryption, and an application that signs in via SAML. Break each layer on purpose, capture pcaps, then write an escalation for the fault you just caused. That is how to practise the kind of reproducible evidence the posting asks for.

Next comes the CV. The posting stresses “direct customer ownership”, so do not write something generic like “supported enterprise customers”. State how many accounts you owned, one escalation you led from start to finish, and one product request you got onto the roadmap.

This end-to-end ownership is not unique to Cisco. Nexus IT Group’s guide to the FDE profession says the work is not done when the architecture sounds right, only when the system runs in the customer’s environment.

If you have only three or four years of experience, treat this posting as a map for the next few years, and pick work that puts your name in front of customers.

Mistakes that sink strong candidates

One mistake to avoid is seeing “FDE” and assuming it is an AI role. The skills listed in the posting revolve around things like TLS and SAML; AI is mentioned as a tool to help read logs, on condition of sound judgement.

Another is telling incident stories as heroics, without being able to explain how you separated what was verified from what was guesswork.

The third is smaller but just as damaging: sending raw configs with the customer’s information still in them. For a security product, leaking customer data in the escalation itself destroys your credibility.

A 45-minute exercise

Run the script above against two domains you often sign in to, once on your home network and once with a VPN or corporate proxy switched on. If the certificate issuer changes, treat it as an “incident” and write an escalation using the template above: scope, evidence, reproduction steps, and at least one line under “Unverified”.

Then give the write-up to a colleague. If they understand what happened without asking you a single question, you have written the kind of escalation this role needs.

In this role, your greatest value is being trusted: engineering opens your escalation and knows straight away it will not have to redo that work from scratch.