Framework overlap

Does NIST SP 800-183 cover 3GPP 5G Security Architecture (TS 33.501)?

You hold NIST SP 800-183 and have been told to do 3GPP 5G Security Architecture (TS 33.501). Here is how much overlaps, control by control.

35% of 3GPP 5G Security Architecture (TS 33.501) you already have

NIST SP 800-183 already covers about 35% of 3GPP 5G Security Architecture (TS 33.501), leaving 28 of 43 controls as genuinely new work.

Already covered 0 Likely covered 15 New work 28

No control in NIST SP 800-183 maps directly to one in 3GPP 5G Security Architecture (TS 33.501). Everything counted as covered is covered because both map to the same third standard, which is what a crosswalk is, but it is an inference rather than a lookup.

What is genuinely new work

Nothing in NIST SP 800-183 reaches these. This is the list to scope.

33.501-10
Security for Interworking with EPS
33.501-11
Security Aspects of IMS
33.501-4.2
Security Domains and Trust Model
33.501-6.1
Primary Authentication (5G AKA / EAP-AKA')
33.501-6.2
Key Hierarchy
33.501-6.7
Security Mode Command Procedures
33.501-8
Security Aspects of UDM/UDR
33.501-9
Security for Non-3GPP Access
33.501-Annex-D
Cryptographic Algorithms
33.501-OAM
Management Plane Security
TS33.501-13.1
NF Registration and Discovery Security
TS33.501-13.2
NF Service Authorization
TS33.501-13.4
OAuth 2.0 Authorization Framework
TS33.501-14.2
Security for Edge Computing
TS33.501-14.3
Security for URLLC Services
TS33.501-14.4
Security for IAB
TS33.501-4.1
5G Security Architecture Overview
TS33.501-4.2
Security Feature Groups
TS33.501-4.3
Security Domains and Stratum
TS33.501-4.4
Network Functions in the Security Architecture
TS33.501-6.1
Authentication Framework
TS33.501-6.2
Key Hierarchy and Derivation
TS33.501-6.3
EAP-AKA' Authentication
TS33.501-6.7
Security Key Hierarchy
TS33.501-6.8
Security in Handover
TS33.501-7.1
Untrusted Non-3GPP Access Security
TS33.501-7.2
Security Visibility and Configurability
TS33.501-7.3
Wireline Access Security
Show the 15 you already have
33.501-13.1
Service-Based Architecture Security (TLS)
33.501-13.2
Network Function Service Authorization (OAuth 2.0)
33.501-13.4
SEPP and Inter-PLMN Security (N32)
33.501-14
Network Slicing Security
33.501-15
Steering of Roaming Security
33.501-16
Security for User Plane Integrity Protection
33.501-17
Privacy and Pseudonymization
33.501-5.1
Subscription Permanent Identifier Protection
33.501-6.4
NAS Security
33.501-6.5
AS Security (RRC and User Plane)
TS33.501-13.3
N32 Interconnect Security
TS33.501-14.1
Security for Network Slicing
TS33.501-6.4
NAS Security
TS33.501-6.5
AS Security and PDCP Protection
TS33.501-6.6
AS Security

How this is calculated

Already covered means a mapping runs from a control in NIST SP 800-183 to that control. Likely covered means no direct mapping exists but both frameworks map to the same control in a third standard. New work means neither. We keep those separate rather than adding them into one friendlier number, because blending them would present a two-hop inference as a verified fact.

Coverage is not symmetric. Run it the other way and you will get a different number; both are correct.

From 332,959 cross-framework control mappings across 723 frameworks, 531 of them verified against their source documents. It does not tell you that you are compliant: a mapped control means the two standards ask for the same thing, not that you have done it.

Try another pair ยท Today's edition