ISSAP Cheat Sheet

A law, regulation, directive, or contract creates an obligation through its governing authority, while a framework or guideline is voluntary unless that authority incorporates it. The architect must establish applicability before treating published guidance as a compliance mandate.

Trap Treat every cited framework as independently mandatory

ISO/IEC 27001 specifies requirements for establishing, implementing, maintaining, and continually improving an ISMS using a risk management process. It is the certifiable management-system standard, not merely a catalog of technical safeguards.

Trap Use ISO/IEC 27002 as the certifiable requirements standard

CSF 2.0 supplies a technology-neutral taxonomy of cybersecurity outcomes and points to informative resources for practices and controls. An architect tailors those outcomes to mission, risk appetite, and sector rather than treating the Core as a fixed control baseline.

Trap Implement every CSF outcome through a prescribed NIST technology

NIST SP 800-53 provides flexible security and privacy controls that address requirements from missions, laws, policies, standards, and guidelines. Selecting the entire catalog without scoping, tailoring, and allocating controls does not produce a risk-based architecture.

Trap Adopt the complete control catalog unchanged

Mappings between standards provide a general indication of coverage, but relationships may be subjective and are not necessarily one-to-one. Compliance must therefore be validated against the source requirement and its scope instead of inferred from a crosswalk alone.

Trap Accept a mapped control as conclusive proof of compliance

The architect identifies relevant laws, regulations, contractual duties, and internal policies by examining mission, sector, jurisdictions, stakeholders, data processing, and services. A control cannot be justified as compliant until the requirement's subject, scope, and triggering conditions apply.

Security architects should obtain authoritative interpretations of laws and regulatory conflicts from qualified legal and privacy stakeholders. Their architectural role is to convert those interpretations into verifiable security and privacy requirements, not to make unsupported legal determinations.

Trap Let the architect independently resolve ambiguous law

Applicable requirements include internal policies and mission needs as well as external mandates. Meeting a regulatory minimum does not satisfy a stricter organizational baseline unless the authorized policy owner approves an exception or changes the policy.

Trap Stop control selection at the least demanding regulation

A defensible architecture maps each source obligation to implemented or inherited controls, responsible owners, assessment methods, and retained evidence. This traceability exposes coverage gaps and lets an assessor follow a requirement from authority to operating proof.

The architecture defines systems, data flows, facilities, people, external services, and interconnections that can affect the regulated service or information. Arbitrarily excluding a connected dependency can invalidate both control design and compliance evidence.

Trap Limit scope to hosts that directly store regulated records

An organization need not be established in the EU for GDPR obligations to apply when its processing relates to offering goods or services to people in the EU or monitoring their behavior in the EU. Physical establishment alone is therefore not a sufficient test of applicability.

An organization remains responsible for managing risks and obligations attached to its mission and information when a supplier performs the work. The architecture must allocate shared controls and evidence duties explicitly rather than assuming the provider's program satisfies the acquirer automatically.

Trap Treat supplier certification as a transfer of accountability

Controls implemented across the system life cycle often depend on prime contractors and their sub-tier suppliers. Contracts must identify which security, privacy, assurance, and reporting requirements flow down so that outsourcing depth does not break the control chain.

C-SCRM uses risk-based due diligence and assessment before selection or acceptance, followed by reviews and monitoring during performance. A one-time procurement questionnaire cannot address later ownership, development, vulnerability, or service changes.

Trap Perform supplier assessment only after contract award

Notification agreements establish which incidents, vulnerabilities, component changes, or supply disruptions a supplier reports, to whom, and within what required timeframe. Without these terms, the customer cannot reliably meet its own response and reporting obligations.

Provenance records help track origin, ownership, custody, and changes so components can be validated as genuine and unaltered. An SBOM adds software-component visibility for vulnerability and dependency analysis, but does not by itself prove that those components are secure.

Trap Treat an SBOM as a product security certification

Data processing includes collection, generation, use, transformation, logging, retention, disclosure, sharing, transmission, and disposal. Privacy architecture must therefore follow data and derived records through every lifecycle action rather than protect only stored databases.

NIST guidance recommends minimizing the use, collection, and retention of PII to what is necessary for mission or business purpose and periodically reviewing holdings. Encryption reduces disclosure risk but does not justify collecting unnecessary personal data.

Trap Retain all encrypted PII for possible future use

Protection level considers identifiability, quantity, field sensitivity, context of use, obligations, access, and location. The same data element may create different harm when combined with other fields or used in a more sensitive context.

Privacy risk includes problems individuals may experience from data processing even when confidentiality, integrity, and availability are not breached. A security risk assessment alone therefore cannot replace analysis of purpose, predictability, autonomy, and potential effects on individuals.

Trap Limit privacy analysis to unauthorized disclosure scenarios

Removing direct identifiers does not necessarily prevent records from being linked back to individuals through remaining attributes or external data. The architect selects de-identification techniques and release controls according to the intended use and credible re-identification threat.

Trap Declare data anonymous after masking names alone

GDPR processing is lawful only when an applicable Article 6 basis supports the purpose, such as consent, contract necessity, legal obligation, vital interests, public task, or a qualifying legitimate interest. The controller should determine and document that basis before processing and provide the required transparency to the data subject; a technical ability or business desire to use the data is not a lawful basis.

Privacy by design integrates appropriate technical and organizational safeguards when processing means are chosen and while processing occurs. Privacy by default limits the amount collected, extent of processing, retention, and accessibility to what each specified purpose requires without relying on the individual to tighten permissive settings.

When consent is the selected GDPR basis, it must be freely given, specific, informed, and unambiguous, and the controller must retain evidence that it was obtained. Withdrawal must be as easy as giving consent and must stop future consent-based processing; consent is one possible lawful basis, not a universal prerequisite or permanent permission.

The controller determines the purposes and means of processing and must select processors that provide sufficient compliance guarantees. A written, binding processing agreement defines scope, duration, data, responsibilities, security, assistance, return or deletion, and documented instructions; delegating execution to the processor does not remove the controller's accountability to demonstrate compliant processing.

GDPR rights include information and access, rectification, erasure, restriction, portability, objection, and safeguards concerning automated decisions and profiling. The architecture must therefore support finding data by subject, supplying intelligible copies, correcting or deleting records, restricting downstream use, exporting portable data, propagating objections, and governing automated-decision workflows.

Under GDPR, a processor notifies its controller without undue delay, and the controller notifies the supervisory authority without undue delay and, where feasible, within 72 hours unless the breach is unlikely to risk people's rights and freedoms. When high risk is likely, the controller also communicates with affected data subjects without undue delay unless a specified exception, such as effective protection that renders the data unintelligible, applies.

The BIA determines process criticality and outage impacts, identifies supporting resource requirements, and establishes recovery priorities. A general risk assessment informs the BIA but does not replace its continuity-focused deliverables.

Trap Use vulnerability scan severity to set recovery order

The recovery time objective expresses how quickly a system or process must be restored after disruption. The recovery point objective expresses the acceptable age of restored data and therefore drives backup or replication frequency.

Trap Use RTO to specify the acceptable backup age

Relocating processing or storage adds resilience only when the alternate capability has suitable capacity, dependencies, accessibility, and separation from threats affecting the primary site. Nominal redundancy inside one shared failure domain can still leave a single point of failure.

A resilient architecture anticipates that some preventive controls will fail and preserves essential operations, possibly in a degraded state, while enabling rapid recovery. Boundary protection alone is insufficient for attacks, environmental disruptions, and human errors that penetrate or bypass it.

Testing validates recovery capabilities, training prepares personnel for their assigned duties, and exercises reveal coordination and planning gaps under scenarios. A tabletop discussion cannot provide the same assurance as executing technical recovery in an operationally representative environment.

Trap Treat a plan walkthrough as proof of technical failover

Maximum tolerable downtime is the total duration a mission or business process can be disrupted without significant harm. The system RTO plus the time needed to recover lost work must not exceed that limit.

A BCP sustains mission or business processes during and after disruption, while a COOP plan sustains an organization's mission-essential functions, typically at an alternate site. A cyber incident response plan addresses malicious cyber events, whereas a disaster recovery plan relocates information-system operations after a major facility disruption. An ISCP restores an individual system at its current or an alternate location and may operate alone or under the broader plans.

Contingency plans should be reviewed on an organization-defined schedule and whenever significant changes affect systems, interconnections, suppliers, facilities, personnel, responsibilities, or organizational requirements. Material changes may require updating the BIA, recovery priorities, procedures, contacts, agreements, and controlled plan copies so the documented strategy remains viable.

Activation and notification applies outage criteria, declares the plan, assesses the disruption, and mobilizes affected parties; recovery restores prioritized capabilities using the selected strategy. Reconstitution validates recovered data, functionality, and controls before resuming normal operations and formally deactivating the plan.

For standards such as PCI DSS, scope includes the protected data environment and system components that store, process, transmit, or can affect the security of that data. Segmentation can reduce scope only when its effectiveness is established and maintained.

An attestation or assessment report must be checked for entity, service, location, period, exclusions, and customer responsibilities. The existence of current provider evidence does not establish that the customer's configuration and retained controls are compliant.

Trap Accept a provider attestation without reviewing its scope

Certification provides independent confidence that the organization operates an ISMS conforming to the standard within the certificate's defined scope. It is not a blanket guarantee that every product, location, or information system is secure.

Under Common Criteria, a Protection Profile expresses implementation-independent security requirements for a class of products. A Security Target identifies the particular target of evaluation and the functional and assurance requirements against which that target is evaluated.

Trap Use a Protection Profile as the evaluated product's specific claim

A Common Criteria evaluation determines whether a defined target satisfies specified security properties at a stated assurance depth. A higher assurance package increases evaluation rigor but does not prove freedom from all vulnerabilities or suitability for every operating environment.

Trap Select the highest EAL as proof of universal product security

PCI DSS defines baseline technical and operational requirements designed to protect payment account data, including cardholder data and sensitive authentication data. Its intended audience spans entities involved in payment-card processing, including merchants, processors, acquirers, issuers, and service providers, rather than only the organization that accepts the card at checkout.

Verification compares architecture or implementation evidence with defined requirements, constraints, and design criteria. It answers whether the system was built according to specification, not whether the selected specification satisfies the user's operational need.

Trap Acceptance testing focused on fitness for operational use

Validation evaluates whether the system, in its operational context, satisfies stakeholder needs and intended use. A design can verify against an incomplete requirement set yet fail validation because it solves the wrong operational problem.

Trap A requirements trace showing every written requirement was implemented

Functional acceptance testing demonstrates that required functions and security behavior satisfy agreed acceptance criteria in the intended context. Passing developer unit tests is supporting evidence, but it does not by itself demonstrate satisfaction of the complete acceptance criteria.

After a modification, regression testing reruns relevant prior tests to find unintended effects in unchanged functions and controls. Testing only the newly changed feature can miss a security property that the change indirectly invalidated.

Trap Retesting only the new functionality introduced by the change

A useful functional test demonstrates both that authorized operations succeed and that disallowed operations are prevented. Positive-only testing can verify availability of a feature while leaving authorization failure paths untested.

Test scope, depth, detail, and rigor should provide the confidence required for the most significant adverse effect that can occur and the applicable assurance needs. Applying the same shallow test set to every component can waste effort on low-consequence elements and under-test elements whose failure has severe consequences.

Fuzzing repeatedly supplies malformed, unexpected, or generated inputs and monitors for crashes, hangs, memory faults, and other anomalous behavior. It complements specification-based tests by exploring cases developers did not enumerate, but it does not establish complete correctness.

Penetration testing attempts to exploit vulnerabilities in a defined scope to show how controls fail together and what access or impact is achievable. A successful test provides strong evidence for the demonstrated path, while an unsuccessful test does not prove that no other path exists.

Trap Treating failure to exploit during a time-boxed test as proof of absence

NIST defines an attack vector as a segment of the pathway an attack uses to access a vulnerability. Characterize each vector by the source of malicious content, the potentially vulnerable processor, and the nature of the malicious content so reviewers can identify where that segment can be detected or stopped.

Trap An attacker profile and motive

Likelihood addresses the possibility that a threat event will occur and result in adverse impact, while impact addresses the magnitude of harm to operations, assets, people, or objectives. A rare catastrophic scenario and a frequent minor scenario therefore require distinct treatment even if a simple score ranks them similarly.

A threat source does not create the same risk in every architecture; exposure, susceptibility, existing controls, and exploitable weaknesses affect whether its event can succeed. Verification should test the assumptions used to estimate those conditions rather than treating likelihood as an adversary attribute alone.

A design gap is established by comparing required target capability with the existing or proposed implementation and evidence. The analysis distinguishes elements to carry forward from those to add, remove, or replace, avoiding a generic findings list with no target-state trace.

Trap Counting scanner findings without mapping them to target requirements

Threat scenarios, affected assets, vectors, preconditions, and expected consequences provide inputs for selecting abuse cases and assurance activities. This trace lets reviewers test whether proposed controls interrupt the modeled path instead of testing controls in isolation.

A threat model is valid only for its documented system boundary, assumptions, technology, and threat context. New trust relationships, data flows, deployment environments, adversary behavior, or mitigations can invalidate prior conclusions and call for reassessing the affected conclusions.

Trap Reusing the approved threat model unchanged for every later release

A proposed safeguard is relevant when it reduces the probability of successful exploitation, limits the resulting harm, improves detection and response, or removes a required precondition. Merely associating a control family with the affected asset does not demonstrate treatment effectiveness.

When the preferred control is infeasible, a compensating control should provide comparable protection for the same requirement and threat, within the actual environment. Cost or convenience alone does not establish equivalence; the rationale and remaining exposure require evidence and approval.

Trap Any cheaper control from the same control family

A trade study compares how candidate designs satisfy security requirements while accounting for cost, performance, interoperability, usability, lifecycle, and operational constraints. Selecting the technically strongest control without considering mission consequences can produce a design that fails validation.

Layered controls are useful when they act at different points or with different failure modes in the threat scenario. Duplicating the same mechanism at several locations can preserve a common-mode weakness and should not be assumed to provide independent assurance.

Trap Multiple copies of one control with the same dependency and failure mode

Verification of a mitigation does not prove that the risk has been eliminated. The post-treatment likelihood, impact, assumptions, and uncertainty must be recorded so the authorized decision maker can accept the residual exposure or require further treatment.

Trap Closing the risk automatically when its planned control passes a test

A tabletop presents a scenario to participants who discuss responsibilities, coordination, decisions, and expected actions. It is well suited to exposing unclear authorities and procedural gaps but does not demonstrate that production technology can execute the response under load.

Trap Treating successful discussion as proof of technical failover capacity

A simulation represents selected system or operational behavior in a controlled environment so scenarios and assumptions can be explored without production consequences. Its assurance is limited by model fidelity, input quality, and the differences between simulated and operational conditions.

A reviewer can trace use cases, state transitions, trust decisions, and exception paths against requirements and threat scenarios before or without executing the implementation. This method is especially useful for architecture logic and missing behavior, but it cannot by itself prove runtime enforcement.

Trap Using document review as the sole evidence that a runtime control works

Qualified peers can identify omitted viewpoints, inconsistent requirements, unsafe assumptions, and trade-offs that the original design team normalized. Review effectiveness depends on reviewer competence, scope, and access to the rationale and evidence, not merely attendance by another architect.

An assessor independent of the design and implementation decisions is less exposed to self-review bias and conflicting incentives. Independence does not replace technical competence or adequate evidence, so an external label alone is not sufficient assurance.

Trap Choosing an external assessor solely because third-party status guarantees quality

Assessment methods commonly examine artifacts, interview responsible people, and test mechanisms or processes. Corroborating these sources distinguishes a documented design, an understood practice, and an operating control instead of inferring all three from one source.

A Common Criteria result provides assurance only for the defined Target of Evaluation and the security claims and properties specified by its Security Target or claimed Protection Profile, as examined by the applicable evaluation methods and activities. It does not provide general assurance for unevaluated functions, configurations, or operating conditions.

Human review can reason about authorization logic, workflow abuse, trust assumptions, misuse of security functions, and requirement omissions that pattern-based tools may not understand. It is resource intensive, so threat models and criticality should focus review on high-risk code and interfaces.

Static analyzers examine code structure and data or control flows to identify weakness patterns before or independently of execution. They can cover large codebases consistently but require triage because findings can include false positives and context-dependent results.

Trap Dynamic analysis of application responses during execution

Dynamic analysis supplies inputs to a running application and observes its behavior and responses. It can reveal runtime and configuration-dependent flaws but sees only the paths, states, and interfaces reached during testing.

Trap Assuming a clean dynamic scan proves unexecuted paths are secure

SCA inventories libraries and other dependencies so teams can assess known vulnerabilities, versions, provenance, and other supply-chain concerns. It does not determine whether the organization's own business logic correctly enforces security requirements.

Trap Using SCA as a replacement for reviewing first-party authorization code

The SSDF calls for reviewing third-party components in the context of their expected use and repeating evaluation when that use changes substantially. A component acceptable in an isolated tool may carry different risk when placed on a critical trust boundary.

Mapped assets, trust boundaries, abuse cases, and attack paths identify where manual review, static analysis, dynamic analysis, fuzzing, and penetration testing provide the most value. Tool coverage metrics alone should not determine security test priorities.

Developer verification records discovered issues, determines their validity and priority, routes remediation into the development workflow, and verifies the fix. Counting tool alerts without disposition and regression evidence is not a completed review process.

Trap Using the raw scanner report as final assurance evidence

Secure code review audits application source to verify that security and logical controls are present, operate as intended, and are invoked in the right places. Its objective is to discover security defects and potentially identify solutions.

Trap Successful execution of each control in isolation proves that the control is invoked at every required point.

Select encryption for confidentiality, a MAC for symmetric integrity and source authentication, and digital signatures when public verification and signer evidence are required. No single primitive automatically supplies every security property.

Symmetric algorithms efficiently protect bulk data but require communicating parties to share secret keying material. Asymmetric techniques support signatures or key establishment without a pre-shared pairwise secret but impose different trust and computational costs.

A hash produces a fixed-length digest intended to make reversal and collisions infeasible; it does not use a decryption key to recover plaintext. Use it for integrity constructions and fingerprints, not to hide predictable sensitive values by itself.

FIPS 140-3 validation provides assurance about a cryptographic module's specified implementation and boundary. It does not certify the security of the entire application, key-management process, protocol design, or surrounding system.

Threat models should include side channels, weak randomness, protocol misuse, key exposure, fault attacks, and insecure error handling in addition to mathematical attacks. Selecting an approved algorithm does not compensate for an implementation that leaks keys.

Inventory algorithms, keys, certificates, protocols, dependencies, and protected-data lifetimes so systems can migrate before current protection becomes inadequate. Long-lived data may require transition earlier than short-lived data because attackers can retain ciphertext for later decryption.

FIPS 140-3 defines four increasing qualitative module-security levels, not one universal assurance target. Select a validated module level whose protections fit the application's security requirements, data sensitivity, operating environment, and exposure rather than choosing a level solely because it is higher.

Disk, volume, file, object, or database encryption can protect data when storage media or copies are obtained without authorization. It does not protect plaintext after an authorized process has unlocked and read the data.

Use a protocol such as properly authenticated TLS or IPsec when data needs confidentiality and integrity over an untrusted path. Encryption without peer authentication can establish a protected channel to an attacker.

Trusted execution environments and secure enclaves can isolate code and data while they are processed and can support attestation of execution state. They reduce exposure to other platform layers but still depend on correct code, trusted roots, and sound key release policy.

With link encryption, each network hop may decrypt and re-encrypt data, so intermediaries can see plaintext. End-to-end encryption keeps content protected between communicating endpoints, although intermediaries may still observe routing metadata.

Trap Hop-by-hop link encryption

Select an approved authenticated-encryption construction when ciphertext confidentiality and integrity are both required. Encryption without an integrity mechanism can permit undetected manipulation even when plaintext remains unreadable.

Encrypt data with a data-encryption key and protect that key under a separately managed key-encryption key. This supports scalable data protection and centralized rotation of the wrapping layer without using one long-term key directly for all bulk data.

A valid signature can provide integrity, origin evidence, and public verification according to the certificate and key trust model. Encrypt separately when the signed content also requires confidentiality.

TLS 1.3 (EC)DHE key exchanges provide forward secrecy, while PSK-only use can forfeit it. Its 0-RTT mode reduces connection latency but lacks inherent replay protection, so allow early data only for operations safe to replay and require application-level duplicate handling where applicable.

Generate keys with an approved random bit generator and enough entropy for the intended algorithm and strength. A long key produced from predictable input remains weak regardless of its nominal bit length.

In key agreement, both parties contribute information used to derive keying material rather than one party selecting and sending the final secret key. Bare Diffie-Hellman needs authentication from the surrounding protocol to resist man-in-the-middle attacks.

Trap Unauthenticated Diffie-Hellman

In key transport, one party generates or obtains keying material and protects it for delivery to another party. This differs from key agreement, in which the resulting shared secret is derived from contributions by both sides.

Secret and private keying material needs confidentiality during distribution, while all key associations need integrity and authentic binding to the intended party and purpose. A confidential channel to an unauthenticated recipient can deliver a key securely to the wrong party.

Set cryptoperiods according to algorithm strength, key type, data volume, exposure, operational environment, and consequences of compromise. Rotation schedules should follow risk and purpose rather than use one arbitrary interval for every key.

Do not use one key pair interchangeably for signing, encryption, authentication, and key establishment unless the approved scheme explicitly permits the combination. Purpose separation limits compromise impact and supports distinct lifecycle treatment.

A relying party must validate the certification path, validity period, intended key use, name, and revocation status before relying on the binding. The certificate does not protect the subject's private key from compromise.

Use a hardware security module when keys must be generated, stored, and used under tamper-resistant controls with tightly governed interfaces. An HSM reduces key exposure but does not decide whether callers are properly authorized unless the surrounding design enforces that policy.

Archive or escrow decryption keys when authorized recovery of protected data is a business requirement. Private signature keys generally should not be escrowed because another holder could create signatures as the subscriber and undermine signer accountability.

Trap Signature-key escrow

Protect backup key copies at least as strongly as operational copies, control their restoration, and inventory their locations. Extra copies can prevent permanent data loss but also enlarge the set of targets that can compromise protected data.

Publish and check revocation status promptly when a private key or binding is no longer trustworthy. Revocation does not recover a compromised private key, decrypt previously captured ciphertext, or invalidate every historical signature automatically.

Stop use, revoke or distrust affected credentials, generate replacement keys, distribute new trust, assess exposed data, and re-protect information where required. Waiting for the normal cryptoperiod to expire leaves a known compromised key active.

Crypto erase is effective only when strong encryption covered the target data and all usable copies of the relevant keys can be destroyed. Surviving key backups or plaintext copies defeat the sanitization claim.

Divide sensitive key material or activation information so no single participant possesses the whole value. Merely requiring two approvals while one administrator still knows and can copy the full key is dual authorization, not split knowledge.

Use dual control when generation, activation, recovery, export, or destruction must not be completed by one person acting alone. It can be combined with split knowledge, but the two controls address action authority and secret possession differently.

Two secrets that are both known, or two devices that are both possessed, do not become multifactor merely because two checks occur. MFA requires evidence from distinct categories such as knowledge, possession, and inherence.

Trap Counting a password and a security question as two factors

The architecture should select an authentication assurance level from transaction and system risk, then choose authenticators and protocols that satisfy it. Identity proofing level and authentication level address different risks and need not be numerically identical.

Trap Automatically setting authentication assurance equal to identity assurance

An authenticator is phishing-resistant when its output cannot be replayed to an impostor verifier, commonly through verifier-name binding or cryptographic binding to an authenticated protected channel. Manually entered one-time passwords remain phishable even though they resist simple replay.

Trap Treating any time-limited one-time password as phishing-resistant

A session may begin at lower assurance and require step-up authentication when context or a requested operation raises risk. Elevation should produce assurance sufficient for the protected action and should not make the stronger state persist beyond its justified lifetime.

Trap Relying on post-transaction anomaly review instead of pre-action step-up

NIST digital identity guidance treats a biometric characteristic as a factor used with a physical authenticator, not as an authenticator by itself. This limits replay and substitution risk while providing a local inherence check.

Trap Using a remotely submitted face image as the sole authenticator

Single-factor authentication can satisfy AAL1 and is an architectural option only where basic confidence is adequate. When risk requires AAL2 or AAL3, the architect must select an eligible MFA process; fraud indicators or contextual checks can trigger added controls but do not raise the AAL or substitute for an authentication factor.

AAL3 requires phishing-resistant public-key authentication with a non-exportable private key held in an isolated hardware environment; syncable authenticators therefore cannot satisfy AAL3. Ordinary AAL2 MFA can use exportable authenticators and need only offer, rather than universally require, a phishing-resistant option.

Authentication intent requires the claimant to respond explicitly to each authentication or reauthentication request, such as by entering an output, pressing a button, or reinserting an authenticator. Passive biometric capture or an authenticator response that endpoint malware can trigger without the claimant's knowledge does not establish intent.

Adding a new authenticator changes who can act as the subscriber, so binding requires authentication at an assurance appropriate to the account and notification of the change. An active session alone may be insufficient if it was established at lower assurance.

Trap Allowing any logged-in session to enroll an unrestricted new authenticator

Recovery can bypass the primary authenticator, so its evidence, delay, notification, and fraud controls must match the resulting risk. Strong daily authentication is defeated by weak knowledge-based reset questions.

Trap Using easily researched personal questions to recover a high-assurance account

When an authenticator is lost, stolen, or compromised, the credential service provider should promptly invalidate its binding and establish a replacement through an approved process. Changing an account label or directory password does not revoke an independent token or certificate.

Trap Renaming the account while leaving the compromised certificate valid

Verifiers should store passwords in a form resistant to offline guessing, using salts and a suitable password hashing scheme, rather than reversible encryption or plaintext. Transport protection does not mitigate theft of a weak verifier database.

Trap Encrypting all passwords under one recoverable database key

Authentication services should throttle or otherwise limit consecutive failed attempts against an account or authenticator. Password complexity alone does not control high-volume online guessing, while permanent lockout can create a denial-of-service path.

Trap Using irreversible account lockout as the primary guessing defense

A session inherits no higher assurance than its authentication event and maintains continuity through a protected session secret established at authentication. Overall and inactivity limits must drive reauthentication or termination, while logout or expiry invalidates the binding; successful reauthentication resets the applicable limits.

Kerberos uses a key distribution center to issue a ticket-granting ticket and service tickets, allowing a client and service to authenticate without sending the user's password to each service. Its design depends on protected keys and sufficiently synchronized clocks.

Trap Selecting LDAP merely because directory entries contain user accounts

A network access server can send a RADIUS Access-Request to a centralized server and receive accept, reject, challenge, and authorization attributes. RADIUS accounting is a related protocol function, but base RADIUS does not provide end-to-end protection for every attribute.

Trap Choosing Kerberos as the native AAA protocol for dial-in or network access servers

SAML is suited to browser-based enterprise federation in which an identity provider asserts authentication and attributes to a service provider. The assertion must be validated for issuer, signature, audience, conditions, and replay constraints rather than trusted because it is XML.

Trap Using OAuth access tokens as a direct replacement for SAML authentication assertions

OAuth lets a client obtain limited access to a protected resource on behalf of a resource owner or itself without receiving the owner's credentials. Treating a bare OAuth authorization response as proof of user identity creates an authentication design gap.

Trap Assuming possession of any OAuth access token proves the user's identity to the client

LDAP defines operations for accessing and modifying distributed directory entries; XACML defines an attribute-based policy language and request-response model for authorization decisions. Either may support an access-control architecture, but they are not interchangeable authentication protocols.

Trap Selecting LDAP as the policy language for centralized authorization decisions

Use an authorization-code pattern when a client needs delegated access approved by a resource owner; the authorization server mediates that approval without exposing the owner's credentials to the client. Use client credentials only for a confidential client acting on its own resources or under prearranged authority, because client authentication itself is then the grant.

Cross-realm Kerberos depends on inter-realm keys and every permitted realm in the transited authentication path, so services should accept only paths allowed by policy. KDC availability is required to issue new tickets, and compromise of a realm's KDC compromises authentication for its registered principals and relying services.

A relying party should trust assertions only from approved identity providers under defined agreements covering assurance, attributes, keys, incident handling, and lifecycle duties. Protocol interoperability alone does not establish organizational trust.

Trap Accepting assertions from any provider that implements the same federation protocol

Audience and recipient restrictions prevent an assertion issued for one relying party from being accepted by another. Signature validation proves integrity and issuer control but does not by itself establish that the current recipient is authorized to consume it.

Trap Accepting any correctly signed assertion from a trusted issuer

Assertions should carry bounded validity and transaction protections appropriate to their federation assurance level. A stolen bearer assertion can be reused within its accepted scope unless nonce, audience, replay detection, or holder-of-key controls constrain it.

Trap Relying on transport encryption alone after a bearer assertion is stolen

The identity provider and relying party should agree on the minimum attributes and purposes needed for the transaction. Sending a complete enterprise profile increases privacy and breach impact without increasing authentication assurance.

Trap Replicating the full directory record to simplify relying-party integration

Federation reduces duplicate credentials and centralizes authentication, but creates dependency on the identity provider's availability, assurance, and incident response. A stand-alone identity store may be justified where isolation or autonomy outweighs those operational benefits.

Trap Assuming federation always reduces risk because it reduces password stores

FAL1 permits bearer assertions and flexible trust and key establishment, while FAL2 remains bearer-based but requires pre-established trust and strong assertion-injection protection in an RP-initiated transaction. FAL3 requires the relying party to verify subscriber control of a holder-of-key or bound authenticator in addition to validating the assertion, protecting even against a compromised identity provider.

Before associating a new federated identifier with a local account, the relying party must use sufficient asserted attributes to resolve the subscriber uniquely and prevent association with another person's account. Linking an additional identifier should occur only in an authenticated session established through an existing identifier, not solely from a mutable attribute such as an email address.