Embedding controls into function code can create operational friction, slower execution, longer cold starts, and debugging or tracing problems for developers. It also increases the chance of conflict between security and engineering teams. In practice, this can make security harder to maintain and can discourage the consistent use of controls across many functions.
What breaks when security is welded into every function
When controls are embedded directly in serverless function code, security stops being a shared platform capability and becomes a code-path concern. That usually means more duplication, more drift between functions, and more expensive change management. The control may work in a single function, but it becomes harder to standardise, test, and operate consistently across an expanding function estate.
It also shifts security failures into the same lifecycle as feature delivery. A harmless refactor can change enforcement, a hotfix can bypass a check, and teams may hesitate to touch legacy functions because they fear breaking security logic. The practical result is that controls can become brittle exactly where serverless platforms are supposed to be most flexible.
One useful reference point is the scale of the code-secrets problem itself: NHI Mgmt Group’s Ultimate Guide to NHIs notes that 30.9% of organisations store long-term credentials directly in code. That is a warning sign for any design that assumes security embedded in code will remain easy to govern over time.
Why operational friction shows up so quickly
Serverless is optimised for fast deployment and small units of work. Inline security logic often fights both of those goals. More code means more branches to maintain, more repeated checks to review, and more places where developers have to reason about security behaviour before they can ship a change. That raises coordination cost even when the control itself is sound.
Cold starts and execution latency are another common break point. Security routines that are cheap in a traditional always-on service can become noticeable in short-lived functions, especially if they add network calls, policy lookups, or tracing overhead. The issue is not just performance in the abstract, but that the added work lands on every invocation, so even small inefficiencies scale quickly.
The Secret Sprawl Challenge is relevant here because code-embedded controls often sit close to the same place where hardcoded secrets, ad hoc checks, and inconsistent rotation practices accumulate. When security logic and sensitive material live side by side in function code, operational drift becomes much easier to miss.
What practitioners should change in the design
The better pattern is to keep the function focused on business logic and push repeatable enforcement into shared layers where possible, such as platform policies, gateway controls, build-time checks, and centralised secret handling. That does not eliminate code-level validation altogether, but it reduces the number of places where security decisions must be hand-implemented and hand-maintained.
What to verify: Check whether the control can be enforced once outside the function instead of copied into dozens of handlers. If the answer is yes, prefer the shared control path and reserve code-level logic for cases where the function truly needs runtime context.
Common mistake: Treating code embedding as “closer to the workload” and therefore safer. In practice, proximity can just as easily create inconsistency, especially when teams deploy many small functions with different owners, release cadences, and observability quality.
Practitioner takeaway: If a control is important enough to trust, it is usually important enough to centralise, standardise, and observe. Serverless security works best when function code consumes controls, rather than carrying the full weight of enforcement itself.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS 4 — Secure Configuration of Enterprise Assets and Software | Centralise repeatable controls to avoid inconsistent per-function implementation. |
| CIS 5 — Account Management | Inline controls often hide duplicated credentials and access logic across functions. | |
| CIS 8 — Audit Log Management | Embedding controls in code can weaken traceability and complicate investigation. | |
| Recommendation — Apply CIS 4 to standardise security enforcement outside individual functions. Use CIS 5 to centralise account and credential governance for serverless workloads. Use CIS 8 to preserve consistent logging and traceability across functions. | ||
| NIST CSF 2.0 | PR.AC — Access Control | Security checks in code are often an access-control implementation problem. |
| DE.CM — Security Continuous Monitoring | Bespoke in-code controls are harder to monitor and validate consistently. | |
| Recommendation — Implement PR.AC controls outside function code where enforcement can be standardised. Use DE.CM to monitor whether serverless controls are behaving consistently at runtime. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Code-embedded security often coexists with hardcoded secrets and poor rotation. |
| NHI-08 — Excessive Permissions | Inline function controls often mask overprivileged functions that are hard to govern. | |
| NHI-10 — Visibility and Monitoring | Distributed code-level controls make consistent visibility and debugging harder. | |
| Recommendation — Move credentials and secret handling out of function code and into managed controls. Reduce function privilege so code does not need to compensate for excessive access. Instrument functions so control failures and execution paths remain observable. | ||
Related resources from NHI Mgmt Group
- How should development teams think about embedding security controls directly into application code?
- What breaks when organisations try to apply REST security controls directly to WebSockets?
- What breaks when SAP code is modified directly instead of using extensibility and transport controls?
- What breaks when CAD security depends only on firewalls, VPNs, DLP, or PLM controls?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
