Shimming is the act of placing a thin piece of material between two parts to make them fit or function properly. In computing and security, shims are also small intermediary layers that sit between components or calls to adapt interfaces, intercept behaviour, or add compatibility without changing the underlying system.
Shimming in physical systems and software
Shimming is a fitting technique in the physical world, and an integration technique in software. In both cases, the shim exists to bridge a mismatch, but it should be understood as a temporary or corrective layer, not as a substitute for a properly aligned design.
In mechanical use, a shim can correct spacing, alignment, or tolerance problems between parts. In computing, the same idea applies to a thin intermediary layer that adapts interfaces, normalises inputs, or preserves compatibility between components that do not match cleanly.
How software shims work
A software shim sits between two components, libraries, system calls, or APIs and changes the interaction just enough for the larger system to keep working. It may translate parameters, intercept calls, stub out behaviour, or provide compatibility for an older interface without changing the underlying application immediately.
This makes shimming useful during platform transitions, legacy migrations, and troubleshooting, because it can isolate a change while the rest of the system continues to run. The same property also means a shim can become invisible infrastructure, which is helpful for compatibility but easy to forget when teams later review architecture or trust boundaries.
Why shimming matters in security
From a security perspective, a shim is powerful because it can observe, alter, or relay behaviour between components. That can be legitimate, for example when a compatibility layer preserves secure operation during a controlled migration, but it can also become a place where assumptions about authentication, authorization, logging, or input validation are weakened.
Shims are especially relevant when security controls depend on the original call path remaining intact. If a shim changes that path, even slightly, it can create gaps in inspection, break policy enforcement, or make it harder to reason about which component is actually making the decision.
Common failure patterns and design trade-offs
Shims reduce friction, but they also accumulate technical debt when they are left in place after the original incompatibility is gone. A long-lived shim can hide a dependency, mask a version mismatch, or become the default place where exceptions are handled instead of fixing the underlying interface.
The design trade-off is simple: a shim can buy time and compatibility, but it also adds another layer that must be trusted, tested, and maintained. The more a shim changes behaviour rather than merely adapting it, the more it starts to look like part of the system rather than a temporary bridge.
Risk and Threat Considerations
Shims can create security exposure when they intercept sensitive calls, alter control flow, or quietly bypass assumptions about what the original component was supposed to enforce. If a shim is opaque, poorly governed, or introduced without review, it can become a blind spot for integrity, access control, and monitoring.
Failure mechanism: A shim changes behaviour at the boundary between components, which can weaken validation, obscure logging, or bypass a control that was only present in the original path.
Impact: Attackers or careless changes can exploit that boundary to preserve unauthorized behaviour, conceal activity, or create compatibility logic that survives long after the need for it has passed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | CM-3 — Configuration Change Control | Shims alter component behaviour and should be governed as controlled configuration changes. |
| SI-7 — Software, Firmware, and Information Integrity | Shims can change how software behaves and may affect integrity expectations at component boundaries. | |
| AU-2 — Event Logging | Shims may intercept or relay calls, affecting what gets logged and where telemetry is captured. | |
| Recommendation — Require review and approval for shim changes that affect runtime behaviour or control flow. Validate that shim layers do not weaken integrity checks or accepted software behaviour. Ensure shimmed interactions still produce complete, attributable audit records. | ||
| NIST CSF 2.0 | PR.PS-05 — Protective Technology | Shims are a protective or compatibility mechanism that can influence how controls are enforced in the stack. |
| Recommendation — Treat shim layers as part of the protective technology boundary and verify their control effects. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Shims are often used in application and interface adaptation, where secure design and testing matter. |
| Recommendation — Test shimmed code paths for unintended bypasses, weak validation, and logging gaps. | ||