New Relic Hardening Guide

Data Last updated: 2026-08-08

Observability security for API keys, license keys, and log obfuscation

Code Packs: Terraform

View:

New Relic — Requirements Cheat Sheet

All controls condensed. Click any requirement to jump to full implementation details.

Requirement	Description	Rationale

Overview

New Relic is an observability platform ingesting application performance, infrastructure, and log data. REST API, License Keys, and 400+ integrations collect telemetry from production environments. Compromised access exposes application architecture, performance patterns, and potentially sensitive log data.

Intended Audience

Security engineers managing observability platforms
DevOps/SRE administrators
GRC professionals assessing monitoring security
Third-party risk managers evaluating APM integrations

How to Use This Guide

L1 (Crawl): Essential controls for all organizations
L2 (Walk): Enhanced controls for security-sensitive environments
L3 (Run): Strictest controls for regulated industries

Scope

This guide covers New Relic security configurations including authentication, access controls, and integration security.

Authentication & Access Controls
API & Key Security
Data Security
Monitoring & Detection

1. Authentication & Access Controls

1.1 Enforce SSO with MFA

Profile Level: L1 (Crawl) NIST 800-53: IA-2(1)

Description

Require SAML single sign-on with multi-factor authentication for all New Relic access, federating authentication to your corporate identity provider.

Rationale

Why This Matters:

Centralizes New Relic authentication in your corporate IdP so MFA, conditional access, and session policies apply to every login
Local New Relic passwords bypass IdP controls and are prime targets for credential stuffing and phishing
IdP-driven provisioning lets you deprovision departed users centrally, eliminating orphaned accounts with standing access to telemetry
New Relic holds application architecture, performance data, and logs that can reveal sensitive operational detail — a single compromised login can expose all of it

Attack Prevented: Credential theft, phishing, MFA bypass, orphaned-account access

ClickOps Implementation

Step 1: Configure SAML SSO

Navigate to: Administration → Authentication domains
Configure SAML IdP
Enable: SSO required

Step 2: Enable MFA

Configure MFA through IdP
Or enable New Relic MFA
Require for all users

Edition gate: SAML SSO requires a paid New Relic edition — it is available on Standard, Pro, and Enterprise, not only Enterprise. (Authentication domains: SAML SSO, SCIM, and more)

Code Pack: Terraform

hth-new-relic-1.1-enforce-sso-with-mfa.tf View source on GitHub ↗

# Alert policy for SSO bypass detection
resource "newrelic_alert_policy" "sso_bypass_detection" {
  name                = "HTH: SSO Bypass Detection"
  incident_preference = "PER_CONDITION"
}

# Detect logins not using SSO (non-SAML authentication events)
resource "newrelic_nrql_alert_condition" "non_sso_login" {
  account_id                   = var.newrelic_account_id
  policy_id                    = newrelic_alert_policy.sso_bypass_detection.id
  type                         = "static"
  name                         = "HTH 1.1: Non-SSO Login Detected"
  description                  = "Detects authentication events that bypass SAML SSO"
  enabled                      = true
  violation_time_limit_seconds = 86400

  nrql {
    query = "SELECT count(*) FROM NrAuditEvent WHERE actionIdentifier LIKE '%login%' AND description NOT LIKE '%SAML%' SINCE 5 minutes ago"
  }

  critical {
    operator              = "above"
    threshold             = 0
    threshold_duration    = 300
    threshold_occurrences = "at_least_once"
  }

  fill_option = "none"
}

1.2 Role-Based Access

Profile Level: L1 (Crawl) NIST 800-53: AC-3, AC-6

Description

Assign users to groups mapped to least-privilege roles and account scopes so each person can access only the telemetry and administrative functions their job requires.

Rationale

Why This Matters:

Overly broad default access lets any user view all telemetry and change configurations far beyond their role
Least-privilege roles and group-based assignment contain the blast radius if a single account is compromised
Separating admin, standard, restricted, and read-only roles prevents accidental or malicious changes to monitoring and alerting
Mapping groups to roles from your IdP keeps access consistent and auditable as teams change

Attack Prevented: Privilege escalation, lateral movement, unauthorized configuration change, excessive data exposure

ClickOps Implementation

Step 1: Define Roles

Role	Permissions
Admin	Full account access
User	Standard access
Restricted User	Limited data access
Read only	View only

Step 2: Configure Groups

Navigate to: Administration → Access management → Groups
Create groups per team
Assign account/role combinations

Code Pack: Terraform

hth-new-relic-1.2-role-based-access.tf View source on GitHub ↗

# Alert policy for access control monitoring
resource "newrelic_alert_policy" "access_control_monitoring" {
  name                = "HTH: Access Control Monitoring"
  incident_preference = "PER_CONDITION"
}

# Detect role and group changes (privilege escalation / unauthorized access grants)
resource "newrelic_nrql_alert_condition" "role_changes" {
  account_id                   = var.newrelic_account_id
  policy_id                    = newrelic_alert_policy.access_control_monitoring.id
  type                         = "static"
  name                         = "HTH 1.2: Role or Group Change Detected"
  description                  = "Detects changes to user roles, groups, or access grants"
  enabled                      = true
  violation_time_limit_seconds = 86400

  nrql {
    query = "SELECT count(*) FROM NrAuditEvent WHERE actionIdentifier LIKE '%group%' OR actionIdentifier LIKE '%role%' OR actionIdentifier LIKE '%grant%' SINCE 5 minutes ago"
  }

  critical {
    operator              = "above"
    threshold             = 0
    threshold_duration    = 300
    threshold_occurrences = "at_least_once"
  }

  fill_option = "none"
}

1.3 Tune Authentication Domain Session and Upgrade-Request Controls

Profile Level: L2 (Walk) NIST 800-53: AC-11, AC-12, AC-2(1)

Description

Set the session duration and idle timeout on each New Relic authentication domain, and configure how user type upgrade requests are handled so users cannot silently escalate their own access.

Rationale

Why This Matters:

Session length and idle timeout are configured per authentication domain, not globally — a domain left on permissive defaults keeps sessions alive on unattended and shared machines long after the user has walked away
New Relic user type governs what a user can do, and the upgrade-request workflow is the path by which a basic user becomes a full platform user; leaving it on automatic approval turns self-service into self-granted privilege
Setting the domain to require review puts a human between a request and the entitlement, and New Relic caps a user at a small number of requests per day, which blunts request-spam pressure on approvers
Domains hold different populations — contractors, vendors, internal staff — so per-domain settings let you be strict where the risk is highest without breaking everyone else’s workflow

Attack Prevented: Session hijacking on unattended devices, stale session reuse, self-service privilege escalation, approval fatigue

ClickOps Implementation

Step 1: Set Session Controls

Navigate to: one.newrelic.com → Administration → Authentication domains
Select the domain and configure its session duration and session idle timeout
Apply the shortest values your users can tolerate, and set them tighter for domains containing contractors or vendors

Step 2: Gate User Upgrade Requests

In the same authentication domain, set upgrade requests to Require review rather than automatic approval
Assign named reviewers who understand what a full platform user can reach
Note that New Relic limits a user to a small number of upgrade requests in a 24-hour window (6), so a rejected request cannot simply be retried indefinitely

Step 3: Review

Re-check these settings whenever a new authentication domain is created — a new domain does not inherit another domain’s hardening

(Authentication domains: SAML SSO, SCIM, and more)

1.4 Automate Provisioning and Deprovisioning with SCIM

Profile Level: L2 (Walk) NIST 800-53: AC-2, AC-2(4)

Description

Enable SCIM provisioning on the authentication domain so users and groups are created, updated, and — critically — deactivated in New Relic automatically from your identity provider.

Rationale

Why This Matters:

SSO alone authenticates users but does not remove them: an account disabled in the IdP can remain present in New Relic, and any path that bypasses the SSO redirect keeps working against it
SCIM makes deprovisioning automatic, which is the mechanism the SSO control’s deprovisioning rationale actually depends on — without it, “deprovision centrally” is a manual process someone has to remember
Group-based push from the IdP keeps New Relic role assignment in step with team membership instead of drifting after every reorganisation
Automated provisioning also removes the manual account-creation step where over-privileged roles are most often assigned by copy-paste

Attack Prevented: Orphaned-account access after offboarding, standing access for departed staff, role drift, over-privileged manual provisioning

Prerequisites

SCIM provisioning requires a Pro or Enterprise New Relic edition
An IdP that supports SCIM 2.0 user and group provisioning

ClickOps Implementation

Step 1: Enable SCIM on the Authentication Domain

Navigate to: one.newrelic.com → Administration → Authentication domains
Select the domain and switch its source of users to SCIM provisioning
Generate the SCIM bearer token and configure your IdP’s New Relic application with it

Step 2: Scope What Is Pushed

Push only the groups that need New Relic access, not the entire directory
Map each pushed group to the least-privilege New Relic role and account scope from 1.2

Step 3: Verify Deprovisioning End to End

Disable a test user in the IdP and confirm the corresponding New Relic user is deactivated
Treat the SCIM bearer token as a high-value credential — it can manage your entire user population

(Authentication domains: SAML SSO, SCIM, and more)

2. API & Key Security

2.1 Secure API Keys

Profile Level: L1 (Crawl) NIST 800-53: IA-5

Description

Manage New Relic API keys securely.

Rationale

Why This Matters:

API keys are long-lived credentials; a leaked User Key grants programmatic access to query data and modify account configuration, and an exposed License Key lets an attacker inject telemetry into your account
License and Insert Keys authorize data ingestion, so exposure lets attackers inject false telemetry to mask real activity or run up usage costs
Unique keys per service plus periodic rotation limit how long a leaked key stays useful and narrow what each key can reach
Least-privilege key scoping ensures a single compromised key cannot reach the entire account
Key types are not interchangeable in their rotation story — browser keys are embedded in pages users can read, and a mobile app token cannot be deleted or duplicated at all, so exposure there is handled by app-level response rather than by rotating the credential

Attack Prevented: API key leakage, telemetry injection, unauthorized configuration change, data exfiltration

Implementation

Key Types:

Key Type	Purpose	Risk	Notes
License Key	Data ingestion	Medium	The recommended ingest credential; use this rather than an Insights insert key
User Key	API access (NerdGraph, REST)	High	Tied to a user; grants that user’s query and configuration reach
Browser key	Browser agent data ingestion	Medium	Embedded in client-side page source and therefore publicly visible by design — never treat it as a secret
Mobile app token	Mobile agent data ingestion	Medium	Cannot be deleted or duplicated; if exposed, response is at the application level, not a key rotation
Insights insert key	Legacy event insertion	Medium	Legacy — New Relic recommends the License Key instead
Insights query key	Legacy query access	High	Superseded by NerdGraph for querying

Deprecated key types. Insights insert keys are legacy and New Relic recommends the License Key for ingest; Insights query keys have been superseded by NerdGraph for querying; and the old admin keys were migrated to user keys in December 2020. If your runbooks still reference admin keys or Insights keys, they are describing a key model New Relic has moved on from. (New Relic API keys)

Step 1: Audit API Keys

Navigate to: one.newrelic.com/api-keys (or one.newrelic.com → Administration → API keys)
Review all keys — owner, type, and last use
Delete unused keys, and retire any remaining Insights insert or query keys in favour of License Keys and NerdGraph

Step 2: Key Best Practices

Create unique keys per service
Rotate keys periodically
Use least privilege
Exclude browser keys and mobile app tokens from secret-scanning alert policies deliberately and with a documented reason, rather than letting them generate noise that trains responders to ignore key alerts

Code Pack: Terraform

hth-new-relic-2.1-secure-api-keys.tf View source on GitHub ↗

# Create a managed ingest key with a descriptive name for auditability.
# Each service should have its own key -- never share keys across services.
resource "newrelic_api_access_key" "managed_ingest_key" {
  count = var.api_key_user_id > 0 ? 1 : 0

  account_id  = var.newrelic_account_id
  key_type    = "INGEST"
  ingest_type = "LICENSE"
  name        = var.ingest_key_name
  notes       = "Managed by Terraform - HTH hardening pack. Rotate periodically."
}

# Alert policy for API key lifecycle events
resource "newrelic_alert_policy" "api_key_monitoring" {
  name                = "HTH: API Key Lifecycle Monitoring"
  incident_preference = "PER_CONDITION"
}

# Detect API key creation, deletion, or modification
resource "newrelic_nrql_alert_condition" "api_key_changes" {
  account_id                   = var.newrelic_account_id
  policy_id                    = newrelic_alert_policy.api_key_monitoring.id
  type                         = "static"
  name                         = "HTH 2.1: API Key Change Detected"
  description                  = "Detects creation, deletion, or modification of API keys"
  enabled                      = true
  violation_time_limit_seconds = 86400

  nrql {
    query = "SELECT count(*) FROM NrAuditEvent WHERE actionIdentifier LIKE '%apiKey%' OR actionIdentifier LIKE '%api_key%' SINCE 5 minutes ago"
  }

  critical {
    operator              = "above"
    threshold             = 0
    threshold_duration    = 300
    threshold_occurrences = "at_least_once"
  }

  fill_option = "none"
}

2.2 License Key Protection

Profile Level: L1 (Crawl) NIST 800-53: IA-5

Description

Rotate New Relic License Keys on a regular schedule and after any suspected exposure — generating new keys, updating agents, then deactivating the old keys.

Rationale

Why This Matters:

License Keys authorize data ingestion and are widely distributed across agents, configs, and CI pipelines, making leaks likely over time
A leaked License Key lets attackers inject fabricated telemetry or run up ingest costs against your account
Regular rotation and deactivation of old keys bounds the window in which any exposed key remains usable
Updating agents before deactivating old keys avoids monitoring gaps that could hide an ongoing incident

Attack Prevented: License key leakage, telemetry injection, ingest cost abuse, persistent unauthorized access

ClickOps Implementation

Step 1: Rotate License Keys

Navigate to: Administration → License keys
Generate new keys
Update agents
Deactivate old keys

Code Pack: Terraform

hth-new-relic-2.2-license-key-protection.tf View source on GitHub ↗

# Alert policy for license key anomaly detection
resource "newrelic_alert_policy" "license_key_monitoring" {
  name                = "HTH: License Key Anomaly Detection"
  incident_preference = "PER_CONDITION"
}

# Detect unusual data ingest patterns that may indicate key compromise
resource "newrelic_nrql_alert_condition" "license_key_anomaly" {
  account_id                   = var.newrelic_account_id
  policy_id                    = newrelic_alert_policy.license_key_monitoring.id
  type                         = "static"
  name                         = "HTH 2.2: Unusual Ingest Volume Detected"
  description                  = "Detects abnormal data ingest volumes that may indicate license key compromise or misuse"
  enabled                      = true
  violation_time_limit_seconds = 86400

  nrql {
    query = "SELECT rate(bytecountestimate(), 1 minute) FROM Log, Metric, Span SINCE 10 minutes ago"
  }

  critical {
    operator              = "above"
    threshold             = 1000000000
    threshold_duration    = 600
    threshold_occurrences = "all"
  }

  warning {
    operator              = "above"
    threshold             = 500000000
    threshold_duration    = 600
    threshold_occurrences = "all"
  }

  fill_option = "none"
}

3. Data Security

3.1 Configure Data Obfuscation

Profile Level: L1 (Crawl) NIST 800-53: SC-28

Description

Protect sensitive data in logs and traces.

Rationale

Why This Matters:

Application logs and traces routinely capture secrets, tokens, PII, and other sensitive values that should never be stored in an observability platform
Obfuscation rules mask matching patterns at ingest so sensitive data never lands in queryable storage
Drop filters remove entire sensitive log entries, reducing both exposure and retention of regulated data
Minimizing sensitive data in telemetry shrinks the impact if New Relic access is compromised and supports compliance obligations

Attack Prevented: Sensitive data exposure, secret/credential leakage via logs, PII disclosure, compliance violations

Prerequisites

Log obfuscation requires the Data Plus ingest option. It is not an edition feature — an account on any edition without Data Plus does not have obfuscation rules available, and must fall back to drop filters and agent-side redaction. (Log obfuscation UI)

ClickOps Implementation

Step 1: Enable Log Obfuscation

Navigate to: one.newrelic.com → All capabilities → Logs → Obfuscation
Create obfuscation rules
Configure:
- Pattern matching
- Replacement values
- Apply to expressions

Step 2: Configure Drop Filters

Navigate to: one.newrelic.com → All capabilities → Logs → Drop filter rules
Drop sensitive log entries
Audit filter effectiveness

Without Data Plus, this control is not optional — it is unavailable. If obfuscation is out of reach, keep sensitive values out of logs at the source (application-side redaction) and use drop filter rules for whole entries. Do not assume the data is masked because the guide lists the control.

Code Pack: Terraform

hth-new-relic-3.1-configure-data-obfuscation.tf View source on GitHub ↗

# Obfuscation expressions for each sensitive data pattern
resource "newrelic_obfuscation_expression" "sensitive_patterns" {
  for_each = { for idx, pattern in var.obfuscation_patterns : pattern.name => pattern }

  account_id  = var.newrelic_account_id
  name        = "HTH: ${each.value.name}"
  description = "Obfuscation pattern for ${each.value.name} - managed by HTH hardening pack"
  regex       = each.value.pattern
}

# Obfuscation rule applying all patterns to log data
resource "newrelic_obfuscation_rule" "sensitive_data_masking" {
  for_each = { for idx, pattern in var.obfuscation_patterns : pattern.name => pattern }

  account_id  = var.newrelic_account_id
  name        = "HTH: Mask ${each.value.name}"
  description = "Mask ${each.value.name} in log messages - managed by HTH hardening pack"
  filter      = "message IS NOT NULL"
  enabled     = true

  action {
    attribute    = ["message"]
    expression_id = newrelic_obfuscation_expression.sensitive_patterns[each.key].id
    method       = "HASH_SHA256"
  }
}

# Alert on obfuscation rule matches to track sensitive data exposure
resource "newrelic_alert_policy" "data_obfuscation_monitoring" {
  name                = "HTH: Data Obfuscation Monitoring"
  incident_preference = "PER_CONDITION"
}

resource "newrelic_nrql_alert_condition" "obfuscation_effectiveness" {
  account_id                   = var.newrelic_account_id
  policy_id                    = newrelic_alert_policy.data_obfuscation_monitoring.id
  type                         = "static"
  name                         = "HTH 3.1: High Volume of Obfuscated Data"
  description                  = "Detects high volumes of obfuscated sensitive data, indicating potential data leak in telemetry pipeline"
  enabled                      = true
  violation_time_limit_seconds = 86400

  nrql {
    query = "SELECT count(*) FROM Log WHERE message LIKE '%OBFUSCATED%' SINCE 30 minutes ago"
  }

  warning {
    operator              = "above"
    threshold             = 1000
    threshold_duration    = 1800
    threshold_occurrences = "all"
  }

  fill_option = "none"
}

3.2 Data Retention

Profile Level: L1 (Crawl) NIST 800-53: SI-12

Description

Review and tune data retention periods for each telemetry data type so data is kept only as long as operationally and legally required.

Rationale

Why This Matters:

Indefinitely retained telemetry expands the volume of sensitive data exposed by any account compromise
Setting retention per data type enforces data minimization and aligns storage with legal and regulatory requirements
Shorter retention for sensitive data types reduces the window in which historical logs and traces can be exfiltrated
Documented retention settings support audit and compliance reviews

Attack Prevented: Excessive data exposure, compliance violations, retention of regulated data beyond policy

ClickOps Implementation

Step 1: Review Data Retention

Navigate to: one.newrelic.com → Administration → Data management → Manage data retention
Review retention per data type
Adjust as needed

Code Pack: Terraform

hth-new-relic-3.2-data-retention.tf View source on GitHub ↗

# Alert policy for data retention compliance monitoring
resource "newrelic_alert_policy" "data_retention_monitoring" {
  name                = "HTH: Data Retention Compliance"
  incident_preference = "PER_CONDITION"
}

# Detect data retention setting changes via audit events
resource "newrelic_nrql_alert_condition" "retention_changes" {
  account_id                   = var.newrelic_account_id
  policy_id                    = newrelic_alert_policy.data_retention_monitoring.id
  type                         = "static"
  name                         = "HTH 3.2: Data Retention Change Detected"
  description                  = "Detects modifications to data retention settings"
  enabled                      = true
  violation_time_limit_seconds = 86400

  nrql {
    query = "SELECT count(*) FROM NrAuditEvent WHERE actionIdentifier LIKE '%retention%' OR actionIdentifier LIKE '%dataManagement%' SINCE 5 minutes ago"
  }

  critical {
    operator              = "above"
    threshold             = 0
    threshold_duration    = 300
    threshold_occurrences = "at_least_once"
  }

  fill_option = "none"
}

# Monitor data age to ensure retention policies are functioning
resource "newrelic_nrql_alert_condition" "data_age_compliance" {
  account_id                   = var.newrelic_account_id
  policy_id                    = newrelic_alert_policy.data_retention_monitoring.id
  type                         = "static"
  name                         = "HTH 3.2: Log Data Exceeds Retention Window"
  description                  = "Detects if log data older than the configured retention window still exists"
  enabled                      = true
  violation_time_limit_seconds = 86400

  nrql {
    query = "SELECT count(*) FROM Log WHERE timestamp < ago(${var.log_retention_days} days) SINCE 1 hour ago"
  }

  warning {
    operator              = "above"
    threshold             = 0
    threshold_duration    = 3600
    threshold_occurrences = "all"
  }

  fill_option = "none"
}

4. Monitoring & Detection

4.1 NrAuditEvent

Profile Level: L1 (Crawl) NIST 800-53: AU-2, AU-3

Description

Use NrAuditEvent queries to monitor and alert on account configuration changes, access management activity, and other security-relevant administrative events in New Relic.

Rationale

Why This Matters:

NrAuditEvent records administrative actions such as role changes, key creation, and user management that indicate misuse or compromise
Without active monitoring of audit events, malicious configuration changes and unauthorized access go undetected
Alerting on high-risk events enables rapid response before an attacker can entrench or exfiltrate data
Retained audit query results provide the forensic trail needed to investigate incidents

Attack Prevented: Undetected privilege changes, stealthy account compromise, configuration tampering, delayed incident response

Detection Queries

Code Pack: Terraform

hth-new-relic-4.1-nrauditevent-monitoring.tf View source on GitHub ↗

# Comprehensive alert policy for NrAuditEvent security monitoring
resource "newrelic_alert_policy" "audit_event_monitoring" {
  name                = "HTH: NrAuditEvent Security Monitoring"
  incident_preference = "PER_CONDITION_AND_TARGET"
}

# Detect configuration changes
resource "newrelic_nrql_alert_condition" "config_changes" {
  account_id                   = var.newrelic_account_id
  policy_id                    = newrelic_alert_policy.audit_event_monitoring.id
  type                         = "static"
  name                         = "HTH 4.1: Configuration Change Detected"
  description                  = "Detects configuration changes via NrAuditEvent"
  enabled                      = true
  violation_time_limit_seconds = 86400

  nrql {
    query = "SELECT count(*) FROM NrAuditEvent WHERE actionIdentifier LIKE '%update%' OR actionIdentifier LIKE '%modify%' OR actionIdentifier LIKE '%change%' SINCE 5 minutes ago"
  }

  critical {
    operator              = "above"
    threshold             = var.audit_alert_threshold_critical
    threshold_duration    = var.audit_alert_evaluation_window
    threshold_occurrences = "at_least_once"
  }

  warning {
    operator              = "above"
    threshold             = 3
    threshold_duration    = var.audit_alert_evaluation_window
    threshold_occurrences = "at_least_once"
  }

  fill_option = "none"
}

# Detect API key creation events
resource "newrelic_nrql_alert_condition" "api_key_creation" {
  account_id                   = var.newrelic_account_id
  policy_id                    = newrelic_alert_policy.audit_event_monitoring.id
  type                         = "static"
  name                         = "HTH 4.1: API Key Created"
  description                  = "Detects API key creation events"
  enabled                      = true
  violation_time_limit_seconds = 86400

  nrql {
    query = "SELECT count(*) FROM NrAuditEvent WHERE actionIdentifier LIKE '%apiKey%' AND actionIdentifier LIKE '%create%' SINCE 5 minutes ago"
  }

  critical {
    operator              = "above"
    threshold             = 0
    threshold_duration    = 300
    threshold_occurrences = "at_least_once"
  }

  fill_option = "none"
}

# Detect user additions and permission changes
resource "newrelic_nrql_alert_condition" "user_changes" {
  account_id                   = var.newrelic_account_id
  policy_id                    = newrelic_alert_policy.audit_event_monitoring.id
  type                         = "static"
  name                         = "HTH 4.1: User Addition or Permission Change"
  description                  = "Detects user additions and permission modifications"
  enabled                      = true
  violation_time_limit_seconds = 86400

  nrql {
    query = "SELECT count(*) FROM NrAuditEvent WHERE actionIdentifier LIKE '%user%' AND (actionIdentifier LIKE '%create%' OR actionIdentifier LIKE '%update%' OR actionIdentifier LIKE '%grant%') SINCE 5 minutes ago"
  }

  critical {
    operator              = "above"
    threshold             = 0
    threshold_duration    = 300
    threshold_occurrences = "at_least_once"
  }

  fill_option = "none"
}

# Detect account-level deletions
resource "newrelic_nrql_alert_condition" "deletion_events" {
  account_id                   = var.newrelic_account_id
  policy_id                    = newrelic_alert_policy.audit_event_monitoring.id
  type                         = "static"
  name                         = "HTH 4.1: Deletion Event Detected"
  description                  = "Detects deletion of resources, dashboards, or configurations"
  enabled                      = true
  violation_time_limit_seconds = 86400

  nrql {
    query = "SELECT count(*) FROM NrAuditEvent WHERE actionIdentifier LIKE '%delete%' OR actionIdentifier LIKE '%remove%' SINCE 5 minutes ago"
  }

  critical {
    operator              = "above"
    threshold             = 0
    threshold_duration    = 300
    threshold_occurrences = "at_least_once"
  }

  fill_option = "none"
}

Appendix A: Edition Compatibility

Control	Free	Standard	Pro	Enterprise
SAML SSO	❌	✅	✅	✅
SCIM provisioning	❌	❌	✅	✅
Custom Roles	❌	❌	✅	✅
Audit Events	✅	✅	✅	✅
Log Obfuscation	Data Plus	Data Plus	Data Plus	Data Plus

Notes:

SAML SSO requires a paid edition — Standard, Pro, or Enterprise. SCIM provisioning requires Pro or Enterprise. (Authentication domains: SAML SSO, SCIM, and more)
Log obfuscation is gated by the Data Plus ingest option rather than by edition — adding Data Plus, not upgrading edition, is what makes it available. (Log obfuscation UI)

Appendix B: References

Official New Relic Documentation:

API Documentation:

Compliance Frameworks:

SOC 1, SOC 2, ISO 27001, ISO 42001, FedRAMP, HIPAA, PCI DSS, TISAX
New Relic Regulatory Audits Documentation

Security Incidents:

No major public security incidents identified for New Relic. Monitor New Relic’s security advisories for current information.

Changelog

Date	Version	Maturity	Changes	Author
2026-08-08	0.2.0	draft	Currency pass: corrected the edition matrix (SAML SSO is any paid edition, not Enterprise-only; added a SCIM row; log obfuscation is gated by the Data Plus ingest option, not by edition) and stated the Data Plus prerequisite in 3.1; rebuilt the 2.1 key-type table with browser keys and mobile app tokens and flagged the legacy Insights insert/query keys and the December 2020 admin-key migration; new controls 1.3 (authentication-domain session and upgrade-request controls) and 1.4 (SCIM provisioning); updated console navigation for 2.1, 3.1, and 3.2; removed marketing/Trust Center references from Appendix B. Open question: the “no major public security incidents” line in Appendix B could not be verified this pass and there are unconfirmed reports of a 2023 staging-environment intrusion — re-verify against a primary source when search budget allows. Tier 2: no CIS Benchmark, DISA STIG, or CISA SCuBA baseline covers New Relic. Tier 3/4 not surveyed this pass.	Claude Code (Opus 5)
2026-06-29	0.1.1	draft	Add cheat-sheet Description and Rationale for all controls	Claude Code (Opus 4.8)
2025-12-14	0.1.0	draft	Initial New Relic hardening guide	Claude Code (Opus 4.5)

Contributing

Found an issue or want to improve this guide?

Report outdated information: Open an issue with tag content-outdated
Propose new controls: Open an issue with tag new-control
Submit improvements: See Contributing Guide

New Relic Hardening Guide

Overview

Intended Audience

How to Use This Guide

Scope

Table of Contents

1. Authentication & Access Controls

1.1 Enforce SSO with MFA

Description

Rationale

ClickOps Implementation

1.2 Role-Based Access

Description

Rationale

ClickOps Implementation

1.3 Tune Authentication Domain Session and Upgrade-Request Controls

Description

Rationale

ClickOps Implementation

1.4 Automate Provisioning and Deprovisioning with SCIM

Description

Rationale

Prerequisites

ClickOps Implementation

2. API & Key Security

2.1 Secure API Keys

Description

Rationale

Implementation

2.2 License Key Protection

Description

Rationale

ClickOps Implementation

3. Data Security

3.1 Configure Data Obfuscation

Description

Rationale

Prerequisites

ClickOps Implementation

3.2 Data Retention

Description

Rationale

ClickOps Implementation

4. Monitoring & Detection

4.1 NrAuditEvent

Description

Rationale

Detection Queries

Appendix A: Edition Compatibility

Appendix B: References

Changelog

Contributing