SAP Security for Defense Contractors: Protecting Export-Controlled Data

Jefry Santoso | category: sap-guardian | CTA products: CyberSilo SAP Guardian and ThreatHawk SIEM

---

Defense Industrial Base (DIB) contractors run programs on SAP because bills of materials, project structures, logistics, and vendor networks do not fit in spreadsheets. That same system of record often holds technical data subject to U.S. export control regimes such as the International Traffic in Arms Regulations (ITAR) and the Export Administration Regulations (EAR). When those records sit behind generic ERP roles, broad RFC interfaces, or offshore support models built for commercial plants, export compliance and cybersecurity collide.

This article is educational guidance for security, SAP Basis/security, and compliance practitioners. It is not legal advice. Classification, licensing, and jurisdiction determinations belong with qualified export counsel and your Empowered Official. What follows covers where export-controlled information commonly appears in SAP, SAP-specific risks that create unauthorized disclosure pathways, control design, SAP-aware detection, and evidence export compliance and DSS/DCSA-oriented reviewers typically expect.

The problem for DIB contractors: ERP is an export surface

Export-controlled technical data does not live only in PLM vaults. Once a program is live, SAP often becomes the operational copy: who can see which part number, drawing reference, vendor, shipment, or WBS element. A user who can download a BOM, open a document info record, or pull a logistics extract may move controlled content without ever touching a design repository.

For contractors also working toward CMMC and protecting CUI, controlled unclassified information and export-controlled technical data frequently overlap in the same masters and project records. Perimeter tools and endpoint DLP help, but they do not understand SAP transaction codes, authorization objects, or RFC destinations. Without SAP-native visibility, teams discover export-relevant access only during investigations—or during a compliance review.

Common failure modes are cultural as much as technical: `SAP_ALL` for Basis “until go-live,” temporary SoD exceptions that never expire, production refreshes into DEV with full master data, and offshore support accounts granted display-all access so tickets close faster. Each pattern can undermine export restrictions even when no file leaves as an email attachment.

Where export-controlled data lives in SAP

Treat this as a practical inventory starting point with your export compliance team—not an exhaustive legal map.

Bills of materials and material masters. Multilevel BOMs, classifications, and characteristics can encode composition, performance, or controlled part lineage. Material and BOM table access is high-value for engineering and for unauthorized collection.

Drawing and document references. Document Info Records, object links, and pointers to controlled drawings bridge ERP navigation to technical content. Even when binaries stay in PLM, SAP metadata may itself be sensitive.

Vendor master and purchasing. Supplier records, source lists, and purchasing info for controlled programs can reveal restricted parties, approved sources, and program affiliation—especially when foreign nationals or entities appear in the chain.

Project systems and WBS. Project definitions, WBS elements, and networks often carry program codes, contract references, and work packages. Broad project display can expose structure export officers treat as sensitive.

Logistics and delivery documents. Orders, deliveries, shipments, and export-related fields describe what moved, where, and under which program. Wide download authorizations make logistics extracts a classic bulk-exfiltration path.

Interfaces and downstream replicas. IDocs, PI/PO or CPI flows, RFC-enabled modules, and analytics extracts can replicate controlled subsets into warehouses, MES, or partner portals. Securing dialog users alone is incomplete if an interface user can pull the same tables unchecked.

SAP-specific risks that break export assumptions

Privileged access and the SAP_ALL culture. Profiles such as `SAP_ALL` / `SAP_NEW`, unlogged firefighter IDs, and “display everything” debug access collapse the boundary between commercial and controlled data. Export compliance assumes least privilege; SAP operations often assume convenience.

Segregation of duties (SoD) conflicts. Finance SoD still matters, but export-relevant conflicts include master-data change plus mass download, role administration plus sensitive table display, and transport release plus production access. “Operational” conflicts can still enable unauthorized disclosure.

RFC and interface exfiltration. Trusted RFC destinations, powerful communication users, and poorly logged gateway activity move data that never appears as a dialog transaction—often excused as “integration.”

Change management. Custom Z-reports, open SQL, and ad hoc queries can expose fields standard transactions hide. Unreviewed transports may quietly expand who can read controlled objects.

Production versus DEV/QAS copies. Refreshes that clone production masters into non-production landscapes recreate controlled content where identity controls are weaker and offshore developers may have access. Masking and subsetting are compliance controls, not optional hygiene.

Third-party and offshore support. Remote Basis, AMS, and development centers often need broad access. If personnel are foreign persons under U.S. rules, or work from locations that trigger licensing constraints, the support model itself can become a deemed-export pathway. Contract language does not replace technical access boundaries.

Control design: roles, classification, and logging

Role design with export context. Build roles from job and program need-to-know, not legacy composites. Separate commercial plant access from controlled-program org levels (company code, plant, sales org, project) where possible. Prefer named display roles for controlled materials and projects over global display, and document compensating controls when dual access is unavoidable.

SoD and privilege hygiene. Extend SoD matrices to export-sensitive conflicts, not finance alone. Eliminate standing `SAP_ALL` in production; use firefighter IDs with session recording, ticket linkage, and short TTL. Recertify high-risk roles with export compliance and security jointly reviewing outliers.

Data classification in the ERP. Tag materials, projects, document types, and org units that carry ITAR/EAR technical data or related CUI. Classification should drive authorizations and monitoring priorities—not sit only in a policy PDF.

Logging of sensitive tables and transactions. Retain Security Audit Log coverage for material/BOM, document management, project display/change, user/role admin, table and data browser, query tools, and download-capable reports. Add Read Access Logging / HANA audit where table-level proof is required. Log RFC and gateway activity for communication users on controlled interfaces. Retention should match investigation and audit needs—not a few days of default history.

Environment and third-party controls. Prohibit uncontrolled production refreshes into DEV; use scrubbed subsets for controlled programs. Bind third-party access to named individuals, U.S.-person requirements where mandated, jump hosts, and monitored sessions. Treat interface users as privileged identities with vaulted credentials and destination allow-lists.

Detection with SAP-aware monitoring (CyberSilo SAP Guardian)

Controls without detection degrade into annual reviews. CyberSilo SAP Guardian is built for SAP estates—ECC, S/4HANA, and related stacks—where generic SIEMs often see only opaque syslog. It applies behavioral analytics across native SAP telemetry (Security Audit, HANA audit, gateway, and read-access oriented signals) to surface privilege misuse, anomalous transactions, authorization drift, and suspicious data-access patterns on export-controlled programs.

High-value detections include sudden table-browser or mass-download use by operational accounts; firefighter sessions without tickets or outside approved windows; new or expanded RFC destinations and communication-user privilege growth; anomalous access to controlled material types, plants, or WBS elements; SoD conflicts after role transports; and bulk logistics or BOM extracts outside baseline volume and time.

Where monitoring must join enterprise context—identity anomalies, endpoint alerts, VPN geography, DLP events—forward SAP Guardian findings into ThreatHawk SIEM. Correlation answers what dialog logs alone cannot: Was the download preceded by phishing? Did the same identity touch a sanctioned destination? Is an RFC pull concurrent with a compromised service account elsewhere?

Audit and evidence for DSS / export compliance officers

Reviewers rarely ask for a product logo. They ask for proof that access was limited, monitored, and investigated.

Evidence packs should be able to show: role and user inventories for controlled scopes; SoD conflicts with owners and mitigations; firefighter logs tied to tickets; samples of Security Audit / read-access events for sensitive transactions and tables; interface and RFC inventories with owners and data scope; non-production data-handling procedures; third-party access registers and session records; and incident tickets where anomalous SAP access was triaged.

CyberSilo SAP Guardian turns continuous SAP telemetry into reviewable cases and audit-ready exports instead of one-off SM20 screenshots. ThreatHawk SIEM preserves cross-system timelines when a concern spans ERP and the broader estate. Map artefacts to internal export procedures and, where applicable, overlapping CMMC expectations for CUI—without claiming a tool “certifies” ITAR/EAR compliance on its own.

Practical checklist

• Inventory SAP objects likely to hold export-controlled technical data (BOM/material, DIR links, vendor, WBS, logistics, interfaces) with export officer input
• Remove standing broad privileges (`SAP_ALL` culture) from production; firefighter only with logging
• Redesign roles for least privilege by plant/project/org; recertify high-risk access
• Extend SoD rules to export-sensitive conflicts, not finance alone
• Classify controlled materials/projects/document types; use tags in auth and monitoring
• Enable durable logging for sensitive T-codes, table access, downloads, and RFC/gateway
• Control DEV/QAS refreshes; scrub or subset controlled production data
• Gate third-party/offshore SAP access with identity, location, and session monitoring aligned to export policy
• Deploy SAP-aware detection (CyberSilo SAP Guardian) for privilege, SoD, and data-access anomalies
• Correlate SAP alerts with enterprise telemetry in ThreatHawk SIEM
• Maintain evidence packs for export compliance / DSS-oriented reviews
• Tabletop: unauthorized BOM/logistics extract via dialog user and via RFC—confirm detection and escalation

For defense contractors, SAP is a repository and distribution plane for program-critical, often export-controlled technical data. Protecting it requires SAP-native least privilege, SoD that reflects export risk, disciplined non-production and third-party access, and monitoring that understands transactions and interfaces—not only network flows.

CyberSilo SAP Guardian gives DIB teams continuous, SAP-aware visibility into privilege abuse and sensitive-data access; ThreatHawk SIEM joins those signals to the enterprise when investigations cross systems. Pair both with your Empowered Official’s guidance so technology reinforces—not replaces—export compliance judgment.