Framework overlap

Does API 1164 cover 3GPP 5G Security Architecture (TS 33.501)?

You hold API 1164 and have been told to do 3GPP 5G Security Architecture (TS 33.501). Here is how much overlaps, control by control.

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

API 1164 already covers about 42% of 3GPP 5G Security Architecture (TS 33.501), leaving 25 of 43 controls as genuinely new work.

Already covered 0 Likely covered 18 New work 25

No control in API 1164 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 API 1164 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-13.1
Service-Based Architecture Security (TLS)
33.501-15
Steering of Roaming Security
33.501-16
Security for User Plane Integrity Protection
33.501-17
Privacy and Pseudonymization
33.501-4.2
Security Domains and Trust Model
33.501-5.1
Subscription Permanent Identifier Protection
33.501-6.1
Primary Authentication (5G AKA / EAP-AKA')
33.501-6.2
Key Hierarchy
33.501-6.4
NAS Security
33.501-6.5
AS Security (RRC and User Plane)
33.501-6.7
Security Mode Command Procedures
33.501-8
Security Aspects of UDM/UDR
33.501-Annex-D
Cryptographic Algorithms
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.2
Key Hierarchy and Derivation
TS33.501-6.3
EAP-AKA' Authentication
TS33.501-6.4
NAS Security
TS33.501-6.5
AS Security and PDCP Protection
TS33.501-6.7
Security Key Hierarchy
TS33.501-6.8
Security in Handover
Show the 18 you already have
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-9
Security for Non-3GPP Access
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.3
N32 Interconnect Security
TS33.501-13.4
OAuth 2.0 Authorization Framework
TS33.501-14.1
Security for Network Slicing
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-6.1
Authentication Framework
TS33.501-6.6
AS Security
TS33.501-7.1
Untrusted Non-3GPP Access Security
TS33.501-7.2
Security Visibility and Configurability
TS33.501-7.3
Wireline Access Security

How this is calculated

Already covered means a mapping runs from a control in API 1164 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