Runtime Application Self-Protection

Expanded Definition

Runtime Application Self-Protection, or RASP, is an in-process security control that observes application behaviour while code is executing and can intervene when the behaviour looks malicious or out of policy. In practice, it sits closer to the workload than perimeter tools, which makes it useful when a token, session, or service account is abused from inside a trusted application path. The concept is still used somewhat differently across vendors, so definitions vary across vendors and no single standard governs this yet; in NHI programs, the safest interpretation is a runtime guardrail, not an identity governance control. That distinction matters because RASP can reduce blast radius during active abuse, but it does not establish ownership, prove legitimate assignment, or remove stale access. For baseline identity and access expectations, practitioners often map runtime protection into the broader control philosophy described in the NIST Cybersecurity Framework 2.0. The most common misapplication is treating RASP as a replacement for entitlement review, which occurs when teams rely on detection at runtime after long-lived credentials have already been over-privileged.

Examples and Use Cases

Implementing RASP rigorously often introduces application latency, testing overhead, and deployment complexity, requiring organisations to weigh runtime visibility against operational friction.

• Blocking abnormal API call sequences when a compromised service account begins enumerating resources or attempting privilege escalation inside a microservice.
• Detecting injection-style behaviour at execution time while a backend process is handling secrets, sessions, or delegated access tokens.
• Containing misuse in a sensitive workload after a credentials leak is suspected, then using logs to support incident response and scope analysis.
• Adding a compensating control around legacy applications that cannot immediately support stronger workload identity patterns such as SPIFFE-based identity.
• Limiting damage during an active abuse chain, as seen in incidents like the Schneider Electric credentials breach, where runtime controls can help slow attacker movement while access paths are investigated.

For teams that align application hardening with the NIST Cybersecurity Framework 2.0, RASP is usually treated as a protective technique inside a broader detection and response program rather than as a standalone solution. It works best when paired with workload identity, secret rotation, and review of privileged application paths.

Why It Matters in NHI Security

RASP matters because many NHI incidents begin with valid credentials, not obvious malware. When a service account, API key, or token is stolen, runtime controls may be the only layer that can interrupt suspicious behaviour before data is exfiltrated or administrative actions are completed. That said, RASP cannot correct excessive privilege, weak offboarding, or secrets left valid long after exposure. NHI Mgmt Group research shows that 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, which is why runtime containment must be paired with governance controls and lifecycle discipline. The same pattern appears in the Schneider Electric credentials breach, where credential misuse illustrates how quickly a valid identity can become an attack path. For governance alignment, organisations commonly anchor these controls to NIST Cybersecurity Framework 2.0 categories covering protection and detection. Organisations typically encounter the need for RASP only after a token has been abused in production, at which point runtime containment becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Dynamic Application Security Testing
• Interactive Application Security Testing
• Runtime Environment
• What is the difference between runtime protection and NHI lifecycle management?