A security service edge platform sits in the path of every user's web, SaaS and private application traffic, so whoever controls its tenant controls what the organisation can reach and what it can see. Its admin console sets bypass lists and access policies, its private access connectors sit inside your network, its client runs on every device, its API connectors read your SaaS tenants, and its inspection certificate authority is trusted by every managed browser. This guide is for network and cloud security engineers and platform owners who run a cloud access security broker (CASB) or a wider SSE service. It covers admin roles, the platform's own identities and keys, connectors, the client, configuration integrity, the platform's own logs and the lifecycle. It is vendor-neutral: confirm exact setting names in your vendor's documentation. For architecture, steering and migration, see the SASE and SSE Guide and the CASB Guide.
Key takeaways
- The tenant console is a high-impact admin system. One administrator can add a bypass, open a private application to everyone or switch off inspection, so protect it with dedicated admin identities, devices and approvals.
- Private access connectors are inside your network. Treat their hosts, enrolment tokens and update channel like any other privileged infrastructure that can reach internal applications.
- The platform runs on non-human identities. SaaS API connectors, provisioning tokens, log streaming keys and identity provider trust each need scoping, an owner and an expiry.
- Bypass and allow lists are the quiet failure. Log, approve and expire every change that removes traffic from inspection or policy.
- Keep configuration and audit history outside the tenant. Scheduled policy exports and an audit log in a store SSE administrators cannot change make tampering visible and recovery fast.
What the platform holds and can do
SSE products bundle several functions, typically a secure web gateway, CASB in API and inline modes, zero trust network access and DLP. The components below describe a common architecture; your service may name or split them differently.
| Component | What it holds or can do | If an attacker controls it | Primary control |
|---|---|---|---|
| Tenant admin console | Access policies, bypass lists, inspection rules, app definitions, roles | Adds bypasses, grants access to private apps, disables inspection | SSO with phishing-resistant MFA, role separation, approval for policy changes |
| Private access connectors | Outbound tunnels from your network; reach to internal applications | A route into internal applications, or a host to pivot from | Hardened dedicated hosts, scoped network reach, protected enrolment tokens |
| Endpoint client | Traffic steering, device posture, sometimes a local disable option | Turned off to bypass inspection and policy | Disable protected by code or admin approval, tamper alerts, posture checks |
| CASB API connectors | Read, and often remediation, rights across SaaS tenants | Read every file and message, change sharing | Least-privilege scopes, certificate credentials, conditional access on the connector |
| TLS inspection certificate authority | A CA trusted by every managed device | Interception of traffic the devices trust | Protected key store, no export, rotation plan |
| Identity integration | SAML or OIDC trust, SCIM provisioning token | Forged or added identities; group changes that widen access | Signed assertions, token rotation, alerts on trust changes |
The SASE and SSE Guide already explains why the console should be tier 0 and how to decide fail-open or fail-closed. This page covers the controls that make that real. See also the Tiered Administration and Enterprise Access Model Guide.
Admin roles and console access
| Role | Can do | Should not do |
|---|---|---|
| Tenant administrator | Roles, identity integration, connectors, log streaming | Day-to-day policy edits |
| Access policy author | Draft web, SaaS and private access policies | Publish to production or add bypasses without approval |
| Policy approver | Approve publication of access and bypass changes | Approve their own change |
| Security analyst | Read logs, investigate events, view CASB findings | Change policy, view decrypted content beyond their case |
| Help desk | Look up a user's recent blocks, issue a time-limited client disable code | Edit policy or bypass lists |
| Auditor | Read configuration and audit logs | Change anything |
- Authentication: sign in to the console through your identity provider with SSO and phishing-resistant MFA. The CISA and FBI Secure by Demand guide asks whether standards-based SSO comes at no extra cost and whether MFA is on by default. Keep one documented break-glass local account, because an identity provider outage can also lock you out of the service that steers traffic to it. See the Break-Glass Account Guide.
- Privileged access workstations and just-in-time roles: the NCSC tiers guidance recommends that high-risk actions such as changing security controls are performed only from privileged access workstations, with privileges granted just in time. See the Privileged Access Workstations Guide.
- Staged publishing: where the product separates draft and published policy, require a second person to publish. NCSC notes that privileged access management makes it harder for one person to make a mistake or act maliciously alone.
- Admin access via the platform: if administrators reach the console through the SSE service itself, document an alternative path so a policy mistake cannot lock everyone out.
- Review: review console roles each quarter (our recommendation) and on every leaver or role change.
Private access connectors and the endpoint client
Private access connectors are software you run inside your network that dial out to the service and carry user sessions to internal applications. They are often installed quickly and then forgotten.
- Dedicated hosts: run connectors on hardened, dedicated virtual machines or containers with no other workloads, no interactive users and patching through your normal process. Apply vendor security updates promptly and subscribe to the vendor's security advisories.
- Scope their reach: place each connector in a network segment that can reach only the applications it serves. A connector with flat access to the data centre turns any policy mistake into broad internal access.
- Protect enrolment tokens: provisioning keys that register a new connector to your tenant should be single use or short lived, stored in a secrets manager and revoked once used. See the Secrets Management Guide.
- Watch connector health and inventory: alert on new connectors registered outside a change, on connectors that stop reporting, and on unexpected outbound destinations from connector hosts.
- Protect the client: use client disable or uninstall codes that are per-device or time-limited and logged, block local administrators from stopping the service where the product allows it, and use device posture checks so a disabled client loses private access. Stopping or modifying a security tool is ATT&CK technique T1685 Disable or Modify Tools.
The platform's identities, keys and trusts
| Identity or secret | Needs | Avoid | Credential pattern |
|---|---|---|---|
| CASB API connector per SaaS tenant | Read activity and content; remediation scopes only where policies use them | Global or super administrator roles granted for convenience | Certificate or federated credential; dedicated connector account excluded from interactive sign-in |
| SCIM provisioning token | Create and update users and groups in the SSE tenant | A token with no expiry stored in a shared admin note | Rotated on a schedule; alert on group changes outside the provisioning source |
| SAML or OIDC trust | Authenticate users and administrators | Unsigned assertions, stale signing certificates | Signed assertions, certificate rollover tracked, alert on trust changes |
| Log streaming credential | Push logs to SIEM or storage | Write access beyond the target bucket or index | Write-only scope, destination restricted, rotation |
| Management API keys | Automation, policy export, ticket integration | Keys mapped to tenant administrator | One key per integration, read-only where possible, expiry |
- Constrain OAuth tokens: RFC 9700, the OAuth 2.0 Security Best Current Practice, recommends sender-constrained tokens using mutual TLS or DPoP, audience restriction and asymmetric client authentication. Use them where the SaaS provider and the platform support them.
- Inventory them: record every connector, token and key with owner, scope and expiry in your NHI inventory. See the Service Account Security Guide and the SCIM Provisioning Guide.
- Inspection CA: keep the inspection certificate authority in the service's protected key store or your own hardware security module, never export it, and plan its rotation and removal from device trust stores. The TLS Inspection Guide covers the design.
Bypass lists, configuration integrity and the platform's own logs
A common way an SSE deployment weakens over time is a configuration change rather than an exploit. A bypass added for a broken application, a destination allowed for one team, or a private application group widened to "all users" removes protection without any alert.
| Event to capture | Why it matters | Alert? |
|---|---|---|
| Inspection or steering bypass added or widened | Traffic leaves inspection permanently | Always, with approver and expiry |
| Private application access policy widened | Internal apps opened to more users or devices | Always |
| Admin role assigned, local admin created, SSO or SAML trust changed | Persistence in the tenant (T1078) | Always |
| Connector registered, removed or offline | New route in, or loss of service | Always |
| CASB API connector credential changed or revoked | Added credentials (T1098.001) or blinding | Always |
| Client disable code issued, or many clients disconnected | Endpoint bypass (T1685) | Above a daily baseline |
| Log streaming disabled or destination changed | Loss of visibility | Always |
- Export logs elsewhere: stream admin audit logs to a SIEM or archive that SSE administrators cannot change, in line with NIST SP 800-53 AU-9(2) (separate storage) and AC-6(9) (log privileged functions). Secure by Demand asks SaaS providers to keep security logs available for at least six months at no additional charge; check your contract and export if it is shorter. See the Log Management and Retention Guide.
- Configuration as code: export policies, bypass lists and app definitions through the API on a schedule, keep them in version control and diff each export against the last approved state. An unexplained diff is a detection, and the last good export is your recovery point.
- Bypass hygiene: every bypass carries an owner, a reason and an expiry. Our suggested maximum is 90 days before re-approval.
Lifecycle: buy, deploy, run, retire
| Stage | Security actions |
|---|---|
| Buy | Ask the Secure by Demand questions (SSO, MFA by default, logs in the base product, vulnerability disclosure policy, SBOM). Ask for granular admin roles, staged publishing, policy export APIs, the permission list per SaaS connector, where decrypted content and logs are processed, and vendor staff access to tenant data. See the SASE and SSE Buyer's Guide and SASE and SSE RFP Template. |
| Deploy | Configure SSO, roles, audit export and the break-glass account before steering any traffic; deploy connectors on dedicated hosts in narrow segments; create CASB connectors with minimum scopes; record the baseline configuration export. |
| Run | Quarterly reviews of roles, bypasses, connectors, tokens and keys; connector host patching; client version coverage; configuration diffing; tested fail-open and fail-closed behaviour. |
| Respond | If the tenant or a connector is suspected compromised: revoke admin sessions and API keys, rotate connector and SCIM credentials, compare configuration to the last good export, review private access logs for new paths into internal applications. |
| Retire | Remove clients and connectors through change control, revoke SaaS connector consents and SCIM tokens, remove the inspection CA from device trust stores, remove identity provider trusts, export the audit history you must keep and obtain written confirmation of data deletion. |
Roll back a hardening change, such as narrowing a connector's network reach, by keeping the previous rule documented and restoring only the specific path an application needs, never by reopening the whole segment.
Detection and measurement
- Connector identities used interactively or from outside the platform's documented addresses.
- Configuration drift between the live tenant and the approved export.
- Traffic leaving inspection: the share of web traffic matched by bypass rules, compared with a baseline.
- Client coverage: managed devices without a connected client, compared with the device inventory.
Metrics that show the controls are working:
- Number of tenant administrators (target five or fewer, our suggestion) and the share holding the role just in time.
- Bypass entries past their expiry or with no owner (target zero).
- Percentage of policy publications with a second approver.
- Percentage of SaaS connectors and tokens using certificate or federated credentials, or rotated within policy.
- Private access connectors running a current version and patched host (target 100%).
- Time to detect an unapproved configuration change, measured in tests.
Framework mapping
| Control area | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | ATT&CK threat addressed |
|---|---|---|---|
| Console roles and privileged accounts | AC-2, AC-6, AC-6(5) | PR.AA-05 | T1078.004 Cloud Accounts |
| Connector and SaaS credentials | IA-5, SC-12 | PR.AA-01 | T1098.001 Additional Cloud Credentials, T1528 Steal Application Access Token |
| Policy, bypass and flow control integrity | CM-6, AC-4 | PR.AA-05 | T1685 Disable or Modify Tools |
| Audit log protection | AU-9, AU-9(2), AC-6(9) | PR.PS-04 | T1685 Disable or Modify Tools |
| Traffic monitoring and inspection | SI-4, SC-8 | DE.CM-01 | T1557 Adversary-in-the-Middle (protecting the inspection CA) |
| Provider and supply chain | SA-9 | GV.SC-07 | T1199 Trusted Relationship |
Common failure patterns
- Permanent bypasses: destinations added to the bypass list to fix one broken application stay for years and grow into a large uninspected zone.
- Flat connector placement: private access connectors sit in a server network with reach to everything, so access policy becomes the only barrier.
- Super administrator CASB connectors: API connectors are granted the highest SaaS role during a proof of concept and never narrowed.
- Shared client disable code: one code to switch off the client circulates through the help desk.
- No configuration history: the tenant is the only copy of policy, so tampering cannot be spotted and a bad change cannot be reverted quickly.
- Admin path through the service: administrators can reach the console only through the SSE service, so a policy error locks out the people who can fix it.
Practitioner checklist
- Enforce SSO with phishing-resistant MFA on the tenant console and keep one tested break-glass account and an alternative admin path.
- Separate tenant administration, policy authoring, policy approval, analysis and help desk roles; require a second person to publish.
- Run private access connectors on dedicated hardened hosts in narrow segments, and treat enrolment tokens as short-lived secrets.
- Protect the client with logged, time-limited disable codes and posture checks.
- Scope every CASB API connector to the minimum role and use certificate or federated credentials.
- Rotate SCIM tokens and log streaming credentials, and alert on identity trust changes.
- Give every bypass an owner and expiry, and alert on bypass and private access policy changes.
- Export configuration and audit logs to stores SSE administrators cannot change.
- Document retirement: clients, connectors, consents, tokens, inspection CA and data deletion.
Standards and references
- NCSC: Risk manage administration using tiers
- CISA and FBI: Secure by Demand Guide
- NIST: SP 800-207 Zero Trust Architecture
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
- IETF: RFC 9700 Best Current Practice for OAuth 2.0 Security
- MITRE ATT&CK: T1685 Disable or Modify Tools
Related NHI Mgmt Group resources: SASE and SSE Guide · CASB Guide · TLS Inspection Guide · ZTNA Buyer's Guide · Securing the PAM Vault Itself