Introducing the Neo-Security Architecture

architect

7 min

On this page

The Neo-Security Architecture is a modular and open-standard-based security architecture. It aims to secure, protect and assert legitimate access to APIs and services as well as to applications both on web and on mobile. A centralized system for managing identities, token issuance, federation and related capabilities is critical to building a secure and scalable API platform.

The primary goal of the Neo-Security Architecture is to provide a blueprint architecture that can be used to map new and existing systems against the functions needed to scale securely. It is not intended to be implemented as a whole but rather to be used as a road-map to be prepared when new needs arise.

The Foundations

The main design principle of the Neo-Security Architecture is Separation of Concerns. Each subsystem within the architecture has a singular responsibility, which helps architects map a problem onto an architectural solution.

The second principle of the Neo-Security Architecture is to build on standards. Each function should use the appropriate standards available to integrate with edge applications or internally. This enables easier replacement of components and helps asserting that security is maintained.

The Neo-Security Architecture has five pillars:

An Identity Management System
An API Management System
An Entitlement Management System
An Machine Identity Management System
A Security Operations System

Each of these encapsulate a system function that is loosely coupled with the others. Together the pillars and their subsystems enable secure access for users and applications to APIs. At the heart of the architecture is the Identity Management System, that is responsible for asserting identities to other systems using security tokens.

The Neo-Security Stack of Open Standards

The following is a non-exhaustive list of open standards used in the architecture. The purpose is not to restrict the architecture, but to understand how to adopt security standards vetted by many experts, and the problems that they solve for enterprises.

Pillar	Subsystem	Standards
Identity Management System	Authentication Service	WebAuthn, Passkeys, FIDO, HOTP, TOTP and non-standardized methods
	Federation Service	SAML, WS-Federation, OpenID Connect
	User Management Service	SCIM
	Machine Authentication Service	HTTP Basic Authentication (shared secret), mutual TLS, JWT-based credentials, HTTP signatures
	Token Service	OAuth 2.0, OpenID Connect and JWT-based access token
API Management System	API Security Service	OAuth 2.0 (Introspection, Token Exchange)
	Developer Portal	DCR and DCRM
	API Integration Service	Service mesh
Entitlement Management System	PDP and PEP	AuthZen
	Policy Administration	ALFA, XACML, Rego, Cedar
Machine Identity Management System	*	SPIFFE, WIMSE, X509 Certificates, JWK
Security Operations System	SIEM	OpenTelemetry, Syslog, SET, SSF
	TDR	CAEP, RISC

Some of the standards listed are large sets of specifications. Often only parts of a standard are sufficient to solve functional requirements.

The Identity Management System

The main responsibility of an Identity Management System (IMS) is to handle and describe identities within the system. This means it needs to be capable of directly authenticating users as an Identity Provider (IdP) or by using a Federated Identity via another IdP. It also needs to be able to authenticate applications and describe their identity.

The components of an Identity Management System

No matter the user, whether they are a customer, employee or partner (or whatever user type you may have), the Identity Management System provides a consistent interface for the identities. By authenticating both humans and machines, it is in the unique position to combine identity assertions in a single security token, and maintain trails about delegations.

The resulting security or access token has a crucial role for least-privileges access. It is a short-lived message credential for API requests that conveys to the API Management System enough claims so that it can determine the scope of access for the particular request concerning both the user and application. From this perspective, the Identity Management System, IMS, is delegating access from the user to the application on their behalf. This is a base principle in the OAuth specification.

Since the access token is short-lived, the Neo-Security Architecture enforces a constant refresh and reevaluation of the grant, reducing the risk of over-privileged and standing permissions. As part of an reevaluation, the Identity Management System can, for example, reduce the scope, transform or revoke tokens and access.

The Identity Management System incorporates the following subsystems.

Subsystem	Function
Authentication Service	IdP - Authentication
Federation Service	Federating identity across domains
User Management Service	User provisioning and management
Machine Authentication Service	Authenticating non-human identities
Token Service	Secure token issuance and introspection

The API Management System

The API Management System (AMS) is the logical structure of an API deployment. Its purpose is to service data and functions via APIs and other types of services in a secure manner.

There are three distinct functions of an AMS that are represented in this architecture.

Securing access to APIs
Integration of APIs into services
Developer access to APIs

An API Management System consists of API Security Service, API Integration Service and API Management Service

At a bare minimum, organizations need to secure access to APIs. For this, the API Management System (AMS) depends on the Identity Management System for all identity related operations, and for issuing the access token.

The API Management System incorporates the following subsystems.

Subsystem	Function
API Security Service	Securing access to APIs
API Developer Portal	Developer access to APIs
API Integration Service	Integration of APIs into services

The API Security Service of the API Management System can handle some security concerns on behalf of APIs (microservices). The API Security Service then acts as the police, using identity information from access tokens to enforce access policies. See also the Identity and Access Management Primer for more technical details on how to secure access to APIs.

The Entitlement Management System

Organizations need a strategy for managing many authorization rules. Such a strategy should account for policy reuse and the ability to change some types of authorization rules dynamically. This is where the Entitlement Management System (EMS) comes into play.

The Entitlement Management System is responsible for managing and enforcing authorization policies as well as distributing these to each subsystem that needs enforcement. It enables central policy administration and decentralized enforcement, where the the API Management System with its API Security Services plays a central role in enforcing the policies.

While the Identity Management System pulls out identity-related logic from APIs, the Entitlement Management System pulls out authorization-related logic. This approach is also known as policy-based access control. The benefit is that authorization policies can be added and updated as the business requirements evolve.

For highly regulated and valuable data, the Entitlement Management System usually applies fine-grained policies with attribute-based access control (ABAC). In this way, it can validate users with their current context (such as the network or device), their client applications (like a mobile app or web app) and their requested actions besides their roles and other attributes.

Subsystem	Function
Policy Administration Point (PAP)	Create and manage authorization policies
Policy Retrieval Point (PRP)	Distribution of policies
Policy Information Point (PIP)	Enrichment of attributes
Policy Decision Point (PDP)	Resolves an authorization request to allow or deny
Policy Enforcement Point (PEP)	Enforces decision made by the PDP

The Machine Identity Management System

The Machine Identity Management System is the identity provider for machine identities. It defines the means for machines (software) to authenticate to other machines to secure machine-to-machine or service-to-service communication. The primary responsibility of the Machine Identity Management System is the lifecycle management of digital credentials and identity assertions.

Machines like mobile apps, APIs or workloads, AI agents or lambda functions require a secret like a shared secret, an API key or private key to securely communicate with other machines. Where possible, the Machine Identity Management System replaces shared secrets with digital credentials and related private key material. It automates the creation, rotation and revocation of these digital credentials and related secrets, which enables short-lived credentials to minimize the risk of stolen credentials.

As part of the issuing process, the Machine Identity Management System can also utilize software attestation to only issue credentials to accredited software. Many SPIFFE-compliant implementations, for example, support attestation-based issuance. X509 certificates or JWT-based assertions.

The Identity Management System integrates with the Machine Identity System to authenticate machines. It then represents their identities in security tokens, commonly next to human identities.

Subsystem	Function
Workload Identity System	Workload attestation and credentials management
Secret Vault	Secure storage of shared secrets
Registry	Visibility, accreditation of machine identities

The Security Operations System

Organizations need to have tools to understand secure access at scale. The Security Operations System adds oversight to the architecture. Its main responsibility is to provide visibility that allows for getting insights into previous and current security state within the Neo-Security Architecture.

The Security Operations System gathers and pulls together data from the different systems in the architecture. This allows for monitoring, analyzing and responding to suspicious findings. A basic form of response are alarms and user notifications.

In a proactive setup, the Security Operations System signals events to the Identity Management System, the Entitlement Management System and API Management System so that they automatically adapt and assist in mitigating threats, e.g., by revoking access. The same systems also send signals to the Security Operations System for aggregation and analysis.

Subsystem	Function
Log Aggregation System	Collecting logs
Security Information and Event System	Log and event analysis through security lense
Threat Detection and Response System	Detect and act upon suspicious events or behavior
Discovery	Visibility of unmanaged actors or actions

Conclusion

The Neo-Security Architecture is built on open standards that are accepted and adopted by the market. The Neo-Security Architecture emphasizes Separation of Concerns by defining dedicated services. Because each service is dedicated to its function and loosely coupled to the others through standards, you can update one service independent of another service, making the system easier to manage and develop over time.

The central point of the Neo-Security Architecture is the Identity Management System. The Identity Management system authenticates both users and machines. For the latter, the Machine Identity Management System serves as a complement to the Identity Management. The Identity Management System supplies the API Management System, the Entitlement Management System and the Security Operations Systems with verifiable identity data about users and machines which is relevant and necessary for access control decisions, audits, threat detection and response.

Dive deeper into the pillars of the Neo-Security Architecture in the following articles:

Last updated: 2026-09-30