Identity and Access Management (IAM): Explained
Identity and Access Management (IAM) is the foundational security control plane that authoritatively answers two questions across the digital estate: who is this person, workload, or service, and what are they allowed to do. For CISOs, identity teams, AppSec leads, vulnerability management owners, GRC owners, security architects, and security operations leaders, IAM is the operating discipline that decides how identities are created, authenticated, authorised, governed, and audited across the organisation. This guide covers what IAM is and is not, the six capability layers (Identity Lifecycle and Provisioning, Authentication, Authorisation and Policy, Access Governance and Certification, Privileged and Sensitive Access Control, Audit Logging and Evidence), how IAM differs from ITDR, CIEM, PAM, IGA, CIAM, ISPM, and standalone SSO and MFA, the modernisation shape from legacy directory infrastructure to cloud-native identity, the operating cadence that makes IAM a programme rather than a sign-in service, the recurring adoption pitfalls, the procurement criteria that separate a programme-grade platform from a federated login product, and how the audit and finding side of the IAM record connects to prioritisation, remediation tracking, and audit evidence fulfilment so the identity work does not live in a parallel backlog.
What IAM Actually Is
Identity and Access Management is a security programme and a technology stack. The programme owns the lifecycle of every identity in the organisation from creation through deprovisioning, the authentication flows that prove an identity is who it claims to be, the authorisation policies that decide what each identity can access, the governance discipline that keeps the assignment appropriate over time, and the audit log that captures every consequential identity event so the security organisation, the auditor, and the incident responder can reconstruct what happened. The technology stack is the platform set that implements all of that: an identity provider, a directory service, an SSO and MFA layer, an access governance product, a privileged access manager, and the connector library that wires the platform to downstream applications and infrastructure.
IAM is the foundational control plane the rest of the security programme reads against. AppSec relies on IAM to know which developer changed which service, which reviewer approved which pull request, and which role holds which production grant. Vulnerability management relies on IAM to identify the named owner accountable for a finding and to route remediation to the appropriate team. GRC relies on IAM to evidence access controls at audit and to demonstrate that the segregation-of-duties policy is operating. Detection layers like ITDR rely on IAM event streams as their primary signal source, and SIEM platforms ingest IAM logs as one of the highest-value source classes for correlation and audit.
IAM is the umbrella; several adjacent disciplines sit inside or alongside it. IGA (Identity Governance and Administration) is the governance slice. PAM (Privileged Access Management) is the specialised control layer for privileged identities. CIAM (Customer Identity and Access Management) is the external-facing equivalent for end-customer identities. NHI (Non-Human Identity) security extends IAM into the workload, service-account, and OAuth-grant population that now outnumbers human identities by orders of magnitude in cloud-native estates. The mature organisation reads where each of these disciplines sits inside its identity programme rather than letting them sprawl into disconnected platforms and policies.
The Six Capability Layers of an IAM Platform
A mature IAM platform has six capability layers. The layers depend on each other: a gap in any of them weakens the service the platform produces. Buyers evaluating IAM vendors should benchmark each layer against the named identity populations the organisation actually owns, the named applications it needs to federate, the named authentication flows it expects to operate, the named governance cadence the audit reads against, and the named privileged-access scenarios the threat model says matter, rather than treating the IAM category label as a capability claim.
Layer 1: Identity Lifecycle and Provisioning
Identity Lifecycle and Provisioning covers the authoritative identity record, the source-of-truth integration with the upstream HR and contractor systems, and the joiner-mover-leaver automation that creates, updates, and removes entitlements across downstream applications. The lifecycle layer is what turns a hire event in the HR system into a provisioned mailbox, directory entry, downstream SaaS assignments, and group memberships, and what turns a departure event into the corresponding revocations. Provisioning fidelity (does the downstream entitlement exactly reflect the upstream authoritative record), deprovisioning timeliness (how long between departure and revocation), and orphan-account discipline (does the platform detect entitlements without a live source-of-truth record) are the three operating properties most often inspected at audit.
Layer 2: Authentication
Authentication covers the flows that prove an identity is who it claims to be at the point of access. The layer spans password policy, multi-factor authentication, adaptive and risk-based authentication that varies the challenge based on signal (device posture, geo, time, behaviour), passwordless flows (FIDO2, WebAuthn, passkeys), step-up authentication for high-risk actions, and the SSO layer that federates downstream applications via SAML 2.0 and OIDC. A mature authentication layer ships strong defaults, transparent user-facing consequences (when does this prompt MFA, when does it block, when does it allow), and tight integration with the device posture layer so the policy can read against managed vs unmanaged device, patched vs unpatched, compliant vs non-compliant.
Layer 3: Authorisation and Policy
Authorisation and Policy covers the model for what each identity can do once it has authenticated. The layer spans RBAC (role-based access control: the dominant pattern in workforce IAM where users are assigned to roles and roles hold entitlements), ABAC (attribute-based access control: the policy expressed as Boolean predicates over identity, resource, and environment attributes), and PBAC (policy-based access control: rule engines that compose authorisation decisions across many inputs). The entitlement catalogue is the structured inventory of what each role, attribute, or policy actually grants downstream. Mature platforms ship policy authoring tools, policy testing and simulation, and policy-evaluation observability so the decision chain is reviewable rather than opaque.
Layer 4: Access Governance and Certification
Access Governance and Certification covers the discipline that keeps access appropriate over time. The layer spans access request workflows (named requester, named approver, named justification), periodic access certifications (named reviewer attesting that each access line is still appropriate against the user current role), segregation-of- duties policies (preventing toxic role combinations such as creating and approving the same payment), role mining (discovering effective access patterns and proposing role consolidations), and the audit-grade attestation pack the compliance team reads at framework audit. This is the IGA slice inside IAM; some organisations operate it through a dedicated IGA product and integrate with a separate IAM platform, while others consolidate IGA inside the IAM suite.
Layer 5: Privileged and Sensitive Access Control
Privileged and Sensitive Access Control covers the elevated grants that need dedicated discipline above standard IAM policy. The layer spans PAM integration (credential vaulting for shared privileged accounts, session recording and keystroke capture for privileged sessions), just-in-time elevation (a developer requests temporary production access, approval routes to the on-call lead, the grant fires for the named window then expires), break-glass procedures (the named procedure to bypass standard authentication for emergencies under recorded conditions), dual approval for sensitive actions, and the time-bound grant model that replaces standing privilege with just-enough-access for just-enough-time. This is the PAM slice that sits inside or alongside IAM and produces some of the highest-stakes evidence the audit reads.
Layer 6: Audit Logging and Evidence
Audit Logging and Evidence covers the timestamped record of every consequential identity event with the integrity properties auditors and incident responders read against. The layer spans event coverage (sign-in success and failure, MFA challenges, conditional access decisions, password resets, federation events, role assignments and revocations, policy changes, privileged sessions, break-glass invocations, certification attestations), retention policy support per event class against the named compliance regime, export to SIEM and security data lake for cross-source correlation, and the integrity properties the auditor reads against (immutable storage, tamper evidence, attestation chain). The audit log is what makes IAM defensible at framework audit and what makes incident reconstruction possible at breach.
IAM vs IGA, PAM, CIAM, ITDR, CIEM, ISPM, and Standalone SSO and MFA
IAM overlaps with several adjacent categories. The boundaries are operational rather than strict, and mature security organisations run more than one in parallel. The table below lays out the differences so security leaders can decide what each category actually buys them and where IAM sits relative to the wider identity stack.
| Category | Anchor | Relationship to IAM |
|---|---|---|
| IGA | Identity Governance and Administration: access requests, certifications, segregation-of-duties policy, role mining, audit attestation. | Governance slice inside IAM. Some vendors ship IAM and IGA as one suite; others ship IGA standalone and integrate with a separate IAM platform. |
| PAM | Privileged Access Management: credential vaulting, session recording, just-in-time elevation, break-glass procedures, dual approval for high-risk actions. | Specialised control layer for the privileged identity population. IAM is the umbrella; PAM is the dedicated discipline above it for elevated grants. |
| CIAM | Customer Identity and Access Management: external-facing identity flows for end-customers, consumer registration, social login, consent management, identity verification. | External-facing equivalent for customer identities. Same disciplines (authentication, authorisation, audit) at consumer scale and against consumer-grade requirements. |
| ITDR | Identity Threat Detection and Response: detection and response layer that observes attacks against the identity surface. | Detection layer above IAM. IAM provisions, authenticates, federates. ITDR consumes IAM events to detect when prevention has been bypassed. |
| CIEM | Cloud Infrastructure Entitlement Management: the cloud-control-plane permissions slice. | Cloud-control-plane specialisation. CIEM reads cloud IAM tables (AWS IAM, Azure RBAC, Google Cloud IAM), identifies excessive cloud entitlements, and right-sizes grants. |
| ISPM | Identity Security Posture Management: observes drift on standing identity posture (orphan accounts, stale grants, missing MFA, weak password policy, federation gaps). | Posture cousin to IAM. ISPM reads against the standing IAM state and flags drift; the remediation lands back in IAM. |
| SSO | Single Sign-On: federation layer that authenticates a user once and grants access to multiple downstream applications via SAML or OIDC. | Authentication-layer capability inside IAM. SSO alone is not IAM; an SSO product without lifecycle, authorisation, governance, and audit is a federated login product. |
| MFA | Multi-Factor Authentication: requires more than one authentication factor (something you know, have, or are) before granting access. | Authentication-layer control inside IAM. MFA is a control, not a programme. Standalone MFA without identity lifecycle and governance is one layer of the IAM stack rather than the stack itself. |
| NHI | Non-Human Identity security: service accounts, workload identities, OAuth grants, machine identities. | Identity population extension. Mature IAM programmes now include NHI as a first-class identity class rather than deferring to secrets management. |
IAM is not a replacement for any of these. A programme that runs a strong workforce IAM for the employee and contractor population, a dedicated PAM for the privileged identity population, an IGA layer for governance and certification, a CIAM platform for the customer-facing surface, an ITDR layer for identity-specific detection, a CIEM layer for cloud-control-plane entitlement, and an NHI governance discipline for workload and service-account identities typically has more depth than an IAM-only programme but at higher operating cost. A programme that ships IAM as a replacement for all of those tools usually loses depth on one or more surfaces. The mature pattern is to be deliberate about which identity job each layer owns.
For programmes thinking about how the identity layer fits inside the wider Zero Trust strategy, the Zero Trust Architecture implementation guide covers the Identity pillar in the context of the wider five-pillar model anchored on NIST SP 800-207 and the CISA Zero Trust Maturity Model. IAM is the foundational Identity pillar that the other Zero Trust pillars depend on.
IAM Modernisation: From Legacy Directories to Cloud-Native Identity
Many enterprise IAM programmes still run on a foundation that predates the cloud-native identity era: an on-premises directory service (Active Directory in most cases), a federation broker bolted on top, per-application credentials for the long tail of legacy applications, password-only flows for an embarrassing proportion of the application portfolio, and a governance layer that runs through spreadsheets and quarterly access reviews. Modernisation is the multi-year journey from that posture to a cloud-native identity platform with broader application coverage, faster integration cadence, modern authentication standards, and governance wired into the platform rather than glued on the side.
Wave 1: Identity Estate Inventory
Capture the current identity estate. The directory services in use, the federation broker, the password and MFA policy by application class, the standing entitlement catalogue, the named ownership for each downstream application, and the non-human identity population (service accounts, workload identities, OAuth grants). Document the existing audit log fidelity per source and the existing access certification cadence. Inventory is what makes the rest of the modernisation defensible at audit and at executive review. Programmes that skip inventory rarely finish modernisation cleanly.
Wave 2: Cloud Identity Provider Adoption
Stand up a modern cloud-native identity provider (Microsoft Entra ID, Okta, Ping, Auth0, JumpCloud) alongside the legacy directory and start federating new applications through the new IdP from day one. This wave does not retire the legacy directory; it stops adding to the legacy footprint and creates the modern IdP as the new source of truth for workforce identity. The discipline is to lock in the new IdP as the only federation target for new applications, without exception, even when the legacy path is faster for the first onboarding.
Wave 3: Legacy Application Onboarding
Migrate federation for existing applications onto the new IdP. This is the slow wave. Each legacy application has its own authentication path, its own credential store, its own lifecycle assumptions, and its own audit log shape. The discipline is to onboard applications in waves grouped by ownership, by criticality, and by federation pattern (SAML, OIDC, password-vault adapter, custom). The hardest applications are the ones with shared accounts, hardcoded credentials in deployment manifests, and federation through a broker that the legacy product depends on for licensing. Retiring per-application credentials in favour of true federation reduces the audit log fragmentation and the authentication-layer attack surface.
Wave 4: Authentication Modernisation
Phase out password-only flows in favour of MFA broadly, deploy adaptive and risk-based authentication that varies the challenge by signal, and pilot passwordless paths through passkeys (FIDO2 and WebAuthn). Authentication modernisation lands in production faster than legacy application onboarding because it sits on top of the new IdP rather than depending on per-application changes. The durable pitfall is wiring conditional access without naming the user-facing consequences: which actions prompt MFA, which actions block, which actions allow with logged signal. A black-box policy stack the IT helpdesk cannot defend is a brittle authentication layer.
Wave 5: Governance Integration
Wire lifecycle automation (joiner-mover-leaver), access certifications, segregation-of-duties policies, and role mining on top of the modernised platform. Governance integration is what turns IAM from a federation product into a programme that the audit can read against. The discipline at this wave is to retire spreadsheet-based access reviews in favour of platform-native certification cadence, to define the segregation-of-duties policy explicitly rather than implicitly, and to operate role mining against the existing entitlement record to find the role consolidations that simplify the catalogue without losing coverage.
Modernisation typically runs eighteen months to three years for mid-market organisations and longer for enterprises with deep legacy estate. The durable failure pattern is treating it as a federation project rather than as a programme that also has to retire legacy entitlements, re-baseline ownership, and wire governance into the platform. Programmes that finish modernisation cleanly produce a smaller, defensible identity estate; programmes that stall produce a parallel state where the new IdP coexists indefinitely with legacy directories, per- application credentials, and spreadsheet-driven access reviews.
The IAM Operating Cadence
IAM is a programme rather than a one-time deployment. The operating cadence is what keeps the programme reviewable cycle- on-cycle and what bounds the executive conversation at quarterly governance. Mature programmes operate IAM on a five-stage cadence aligned with the wider security operating model.
Continuous lifecycle and authentication
Joiner-mover-leaver events fire as HR events arrive. Authentication runs continuously against the policy stack. MFA challenges, conditional access decisions, and privileged-access elevations execute per-event. This is the steady-state IAM service.
Daily and weekly operational reads
Daily operational reads of orphan account candidates, deprovisioning timeliness, MFA bypass exceptions, and break- glass account use. Weekly reads of federation health, authentication failure rates by application, and governance-workflow throughput.
Periodic access certifications
Quarterly or biannual access certifications against the in-scope identity population, with named reviewers attesting that each access line is still appropriate against the user current role. Certifications produce the audit-grade attestation evidence the compliance team reads at framework audit.
Monthly executive cadence
Monthly executive read of identity coverage, provisioning latency, deprovisioning timeliness, MFA coverage, federation coverage, standing privilege ratio, certification completeness, and audit log retention coverage. The executive read is what keeps the IAM programme defensible at the board cyber risk briefing.
Quarterly platform and policy review
Quarterly review of the IAM platform itself: connector library coverage against the named application portfolio, authentication policy review against the named threat model, governance workflow tuning, role mining outputs, segregation-of-duties exception review, audit log retention configuration, and the procurement question of whether the platform is keeping pace with the organisation. The quarterly review is the cadence that separates a maintained IAM programme from one that quietly degrades while the steady-state continues.
The Eight IAM Programme Metrics
A defensible IAM programme tracks eight metrics that turn the platform from a sign-in service into a reviewable security programme. The metrics together let the security organisation defend IAM cycle-on-cycle at executive review and at compliance audit, and they expose silent degradation early.
| Metric | What it measures |
|---|---|
| Identity coverage | Proportion of in-scope identities (workforce, contractor, workload, service) managed through the IAM platform rather than through orphan accounts in downstream applications. |
| Provisioning latency | Time from HR event (hire, role change, departure) to the corresponding entitlement change in downstream applications. |
| Deprovisioning timeliness | Time from departure to revocation across all downstream entitlements. The highest-stakes IAM metric for audit and breach defence. |
| MFA coverage | Proportion of in-scope authentication events that completed multi-factor authentication against the policy. |
| Federation coverage | Proportion of in-scope applications federated through the central IdP rather than running per-application credentials. |
| Access certification completeness | Proportion of in-scope access lines reviewed and attested within the programme cadence by the named reviewer. |
| Standing privilege ratio | Proportion of identities holding privileged grants on a standing basis versus through time-bound just-in-time elevation. |
| Audit log retention coverage | Proportion of consequential identity events captured in the audit log against the named retention policy and the named compliance regime. |
IAM Evidence Pack and Compliance Reading
IAM produces several artefact classes that connect into the wider security operating record. The evidence pack is what the auditor, the cyber insurance underwriter, and the incident responder all read against. A mature programme can produce each artefact on request without the months-long evidence scramble that signals a weak underlying programme.
Joiner, mover, and leaver evidence
Per-event record of every identity lifecycle change with timestamp, source event, downstream actions, and verification. Reads against ISO 27001 Annex A 5.16 (identity management), A.5.18 (access rights), SOC 2 CC6.2 (registration and authorisation), CC6.3 (modification and removal), and NIST 800-53 AC-2 (account management).
Authentication and MFA evidence
Per-event authentication record with factor used, conditional access decision, and policy reference. Reads against ISO 27001 Annex A 5.17 (authentication information), SOC 2 CC6.1 (logical and physical access), PCI DSS Requirement 8 (identify and authenticate access), NIST 800-53 IA-2 (identification and authentication), and HIPAA 164.312(d) (person or entity authentication).
Access certification attestation
Per-cycle attestation that each in-scope access line was reviewed by the named reviewer with the named decision (retain, revoke, modify, escalate). Reads against ISO 27001 Annex A 5.18 (access rights) and 8.2 (privileged access rights), SOC 2 CC6.2, PCI DSS Requirement 7.2.4 (periodic review), NIST 800-53 AC-2(7) (privileged user accounts), and NIST CSF 2.0 PR.AA-05 (access permissions).
Privileged access record
Per-session record of privileged access elevation with named requester, named approver, named scope, named time window, and the session activity log. Reads against ISO 27001 Annex A 8.2 (privileged access rights), SOC 2 CC6.6 (logical access restrictions), PCI DSS Requirement 7 and 8, NIST 800-53 AC-6 (least privilege) and AU-12 (audit record generation), and the cyber insurance privileged access evidence the underwriter increasingly requests at renewal.
Cross-regime compliance reading
IAM evidence reads against ISO 27001 Annex A 5.15 to 5.18 and 8.2 to 8.5, SOC 2 CC6 trust services criteria, PCI DSS Requirements 7 and 8, NIST 800-53 AC and IA control families, NIST CSF 2.0 PR.AA (identity management and access control), HIPAA 164.312(a) (access control), DORA Article 9 (ICT security policies and procedures), NIS2 Article 21 (cybersecurity risk management measures), and the GDPR Article 32 access- control expectations for personal data.
Seven IAM Adoption Pitfalls
IAM rollouts fail in characteristic ways. Recognising the recurring pitfalls early is what separates a programme that ships a defensible identity service from one that ships federation and stalls.
- Treating IAM as the SSO project. A federation product without lifecycle, authorisation, governance, privileged access, and audit is one layer of the IAM stack rather than the stack itself. The audit reads against the whole stack, not the SSO layer in isolation.
- Deferring deprovisioning. Shipping fast provisioning while leaving deprovisioning to ticket-based manual workflows leaves the highest-stakes IAM weakness untouched. Stale access from departures and role changes is what most identity-related incidents and audit findings anchor on.
- Black-box conditional access. Wiring conditional access policies without naming the user-facing consequences (when does this prompt MFA, when does it block, when does it allow) produces a policy stack the IT helpdesk cannot defend and that the security team cannot tune.
- Standing privilege. Standing privileged grants across long-lived roles instead of just-in-time elevation leaves a large unprivileged-when-needed attack surface that ITDR and PAM both work harder to compensate for. The standing privilege ratio is the metric to watch.
- Rubber-stamp certifications. Manual access certifications without role mining and without effective-access visibility produce attestations that fail at audit when the reviewer cannot explain what they actually approved.
- Password-vault federation. Wiring legacy applications through password-vault adapters instead of true SAML or OIDC federation creates a brittle authentication layer that breaks under credential changes and leaves the audit log with reduced fidelity.
- Ignoring non-human identities. Treating service accounts, workload identities, and OAuth grants as out of scope for IAM creates the secret-sprawl pattern that the wider NHI discipline now exists to remediate. Modern IAM programmes treat NHI as a first-class identity class.
IAM Procurement Criteria
Vendors marketing themselves as IAM ship products that span a wide quality range: some are mature platforms with deep connector libraries, strong governance, and rich audit logging; others are federation products with a thin governance layer bolted on. The procurement artefact that bounds the conversation is a coverage matrix the buyer fills against the named identity population, applications, authentication flows, compliance regimes, and risk decisions, not a vendor capability checklist filled by the vendor. Eight criteria carry most of the procurement weight.
- Identity model and source-of-truth integration. Native HR-system, contractor-catalogue, and machine-identity integration. Does the platform support the actual upstream authority the organisation operates against.
- Application connector library and SCIM depth. Per-application coverage against the named portfolio. SCIM support across joiner, mover, leaver. The connector library is the integration surface that bounds rollout speed.
- Authentication capability matrix. MFA factor breadth, adaptive and risk-based authentication, passwordless support (FIDO2, WebAuthn, passkeys), step-up flows, and integration with the device posture layer.
- Authorisation model and policy observability. RBAC depth, ABAC and PBAC support, entitlement catalogue, policy authoring, policy testing and simulation, and policy- evaluation observability.
- Governance layer. Access request and approval workflows, periodic certification cadence and tooling, segregation-of-duties policy support, role mining, and the audit-grade attestation pack.
- Privileged access integration. PAM connector, just-in-time elevation, break-glass procedures, dual approval, session recording, and the privileged session audit log.
- Audit log layer. Event coverage, retention policy support, export to SIEM and security data lake, and the integrity properties the auditor reads against.
- Operating-cost shape and vendor cadence. Per-identity, per-application, or per-event pricing model against the organisation operating shape; published cadence for connector library expansion, security update releases, and platform feature releases.
How IAM Connects to Vulnerability Management and Audit Evidence
IAM-related findings have the same operating shape as the wider security finding population. Orphaned accounts, excessive privilege, missing MFA on a federated application, stale grants, failed deprovisioning, segregation-of-duties violations, weak password policy on a legacy application, missing audit log retention on a sensitive source: each is a finding with a named owner, a severity, a remediation action, an evidence pointer, and a closure verification step. Programmes that hold these findings inside the identity platform separate from the wider finding queue have to reconcile two backlogs at audit and at executive review. Programmes that ingest IAM findings into the same operating record as scanner output, pentest findings, bug bounty submissions, and SIEM-validated incidents collapse the audit read and the prioritisation backlog into one source.
The connection points are concrete. Access certifications produce attestation evidence that pairs with the wider audit fieldwork evidence request fulfilment workflow. Privileged access events feed the security leadership reporting cadence. IAM-related vulnerability findings (missing MFA, excessive grants, password policy weakness) flow through the same vulnerability prioritisation and remediation tracking workflow as the rest of the security backlog. Joiner-mover- leaver evidence supports control mapping across frameworks so the same audit evidence can be reused across ISO 27001, SOC 2, PCI DSS, NIST 800-53, NIST CSF 2.0, HIPAA, DORA, and NIS2 reads.
Programmes that wire the connection cleanly produce a single security finding record that reads against the IAM platform, the scanner output, the pentest findings, the bug bounty backlog, and the SIEM incident stream from one operating record. Programmes that do not produce a parallel-backlog problem that grows silently and surfaces at audit.
How SecPortal Pairs with IAM Programmes
SecPortal is not an IAM platform. SecPortal is the security operations and finding-record workspace that the IAM programme connects into on the finding and evidence side. The pairing covers four concrete patterns.
IAM-related findings as first-class records
Orphaned accounts, excessive privilege, missing MFA on federated applications, weak password policy on legacy applications, failed deprovisioning, and segregation-of-duties violations land in findings management with CVSS 3.1 severity, a named owner, a remediation action, an evidence pointer, and a closure verification step. The findings flow through the same prioritisation and remediation workflow as the rest of the security backlog rather than living in the identity platform alone.
Workspace identity controls
SecPortal ships TOTP-based MFA at the workspace boundary, team management with role-based access control across owner, admin, member, viewer, and billing roles, encrypted credential storage using AES-256-GCM for stored authentication credentials scoped to verified domains, and domain verification so authenticated scans are bounded to assets the workspace can prove ownership of. SecPortal does not ship enterprise SSO, SCIM provisioning, or SAML federation; the identity-platform side of the integration is owned by the customer IAM stack.
Audit evidence and activity log
Every consequential workspace event is captured in the activity log with timestamp, named actor, and CSV export. Compliance tracking reads against 21 frameworks including ISO 27001, SOC 2, PCI DSS, NIST 800-53, NIST CSF 2.0, HIPAA, DORA, NIS2, and related identity-relevant regimes. Document management holds IAM policy documents, access certification records, and evidence artefacts alongside the wider security evidence pack.
Bulk intake and AI reporting
Bulk finding import accepts CSV exports from IAM posture management products, ISPM tools, identity governance products, and identity-aware vulnerability scanners so identity-related findings join the same workspace record. AI report generation drafts executive and technical narratives from the live finding record so security leadership reads against the same evidence the operating teams act on. Finding overrides capture the eight-field decision chain when an IAM- related finding is accepted, deferred, or marked compensating so the audit trail is defensible.
Honest scope: SecPortal is not an identity provider, not an IAM platform, not an IGA product, not a PAM vault, not a CIAM platform, not an ITDR engine, not a CIEM tool, and does not ship enterprise SSO, SCIM, or SAML federation. Workspace MFA is provided through TOTP at the SecPortal sign-in boundary, not as a downstream identity service. SecPortal is the security operations workspace that holds the finding record and the evidence pack the IAM programme connects into on the audit and remediation side.
Frequently Asked Questions
What is Identity and Access Management?
The security programme and technology stack that authoritatively answers who an identity is and what it is allowed to do across the digital estate. IAM owns lifecycle, authentication, authorisation, governance, privileged access control, and audit logging.
How is IAM different from IGA?
IGA is the governance and certification slice inside IAM: access requests, joiner-mover-leaver automation, periodic certifications, segregation-of-duties policy, role mining, and audit attestation. Some vendors ship IAM and IGA as one suite; others ship IGA standalone.
How is IAM different from PAM?
IAM is the umbrella for the entire identity population. PAM is the specialised control layer for privileged identities with credential vaulting, session recording, just-in-time elevation, break-glass procedures, and dual approval for high-risk actions.
How is IAM different from CIAM?
Workforce IAM covers internal-facing identities (employees, contractors, partners, workloads, service accounts). CIAM covers external-facing identities (end- customers, B2B customer-side users). The disciplines are the same; the scale and requirements differ.
How is IAM different from ITDR and CIEM?
IAM is the prevention layer. ITDR is the detection layer that observes attacks against the identity surface. CIEM is the cloud-control-plane permissions slice that observes excessive cloud entitlements. Mature programmes operate all three deliberately.
What capability layers should an IAM platform have?
Six layers: Identity Lifecycle and Provisioning, Authentication, Authorisation and Policy, Access Governance and Certification, Privileged and Sensitive Access Control, Audit Logging and Evidence.
What does IAM modernisation look like?
Five waves over eighteen months to three years: identity estate inventory, cloud identity provider adoption, legacy application onboarding, authentication modernisation, and governance integration. The failure pattern is treating it as a federation project.
What metrics should an IAM programme track?
Eight metrics: identity coverage, provisioning latency, deprovisioning timeliness, MFA coverage, federation coverage, access certification completeness, standing privilege ratio, audit log retention coverage.
How does IAM connect to vulnerability management and audit evidence?
Joiner-mover-leaver evidence and access certifications become framework evidence. IAM-related findings (orphans, excessive privilege, missing MFA, stale grants) flow into the same finding record as scanner and pentest output so the audit read and the prioritisation backlog stay collapsed.
What are the common IAM adoption pitfalls?
Treating IAM as the SSO project, deferring deprovisioning, black-box conditional access, standing privilege, rubber- stamp certifications, password-vault federation for legacy applications, and ignoring non-human identities.
What IAM procurement criteria matter?
Eight criteria: identity model and source-of-truth integration, application connector library and SCIM depth, authentication capability matrix, authorisation model and policy observability, governance layer, privileged access integration, audit log layer, operating-cost shape and vendor cadence.
What is the future of IAM?
Passwordless via passkeys, identity verification integrated at high-risk moments, non-human identity as a first-class capability, AI-driven identity analytics, and decentralised identity in early production. Adopt deliberately rather than by default.
Scope and Limitations
This guide describes the operating shape of Identity and Access Management as it is consumed in mainstream enterprise programmes. The vendor landscape evolves rapidly: specific connector libraries, supported authentication standards, the depth of governance capabilities, the integration surface, the licensing model, and the latency and reliability characteristics of named platforms all shift between releases and renewals. Specific feature claims, supported integrations, named compliance certifications, and the operating-cost shape of specific contracts should be verified against current vendor documentation and against benchmark exercises on the organisation own scope.
IAM is the prevention and authorisation foundation, not a detection platform. Programmes that adopt IAM without an underlying identity inventory lose the visibility the platform depends on; programmes that adopt IAM as the foundational control plane, with named populations, named applications, named authentication flows, named governance cadence, named privileged-access carve-outs, and the IAM finding queue wired into the wider security operating record, are the ones that see durable identity-security improvement over time.
Hold IAM findings and evidence on SecPortal
Stand up the operating workspace that holds IAM-related findings and audit evidence alongside scanner output, pentest findings, and SIEM-validated incidents in under two minutes. Free plan available, no credit card required.