Security

Security Architecture

Review responsibilities and controls for document substitution, replay, spoofing and outages.

ON THIS PAGE

PRIVATE KEY BOUNDARY

Private-key operations remain within the applicable signing infrastructure.

Reference architecture

If the table is wider than its frame, scroll horizontally to see all columns; use arrow keys when the table region has focus.

Private-key operations remain within the applicable signing infrastructure.
Threat	Boundary	Prevention / detection	Response / evidence
Document substitution	App → Sign	Bind version, digest and summary	Stop signing; preserve comparison
Authorization replay	User → Provider	Challenge, expiry and transaction binding under contract	Reject; retain event and transaction reference
Webhook spoofing	Provider → App	Validate authenticity, time and duplicates	Quarantine; reconcile source state

CONTROL PLANES

Separate control from execution.

CONTROL

GoPaperless

Policy, transaction, routing, state, evidence.

INTERACTION

Agent / Mobile

User interaction and secure handoff.

SIGNING

CA/RSSP

Credential and signature creation according to provider architecture.

THREAT-LED SECURITY

Security architecture starts with boundaries and abuse cases

Mobile-ID Sign Security avoids marketing phrases such as military-grade. Controls are mapped to document substitution, replay, session hijacking, fake Agent, credential leakage, webhook spoofing, provider outage and evidence tampering.

SECURITY CONTROL MODEL

Eight domains instead of a generic “secure by design” statement

The domains below are anchored in Mobile-ID’s published information-safety policy; implementation detail for Sign remains scope- and deployment-dependent.

Security Governance & ISMS

Management ownership, policy lifecycle, risk assessment, internal audit and continual improvement.

Asset Management

Inventory, ownership, classification and handling of information assets.

Identity & Access

Unique accounts, least privilege, need-to-know/use, MFA for critical systems and offboarding.

System & Data Protection

Endpoint/server safeguards, backups and secure channels for sensitive data.

Application & API Security

Authentication, authorization, secret handling, webhook verification, replay and input validation.

Monitoring & Incident Response

Events are monitored and incidents are recorded, classified, investigated and followed by RCA.

Personnel Awareness

Security awareness for new and existing personnel with training records.

Audit & Improvement

Internal ISMS audit, management review, risk reassessment and corrective action.

Information Safety Policy ↗

INCIDENT RESPONSE

From event to root-cause evidence

Mobile-ID’s published policy states that incidents are recorded, classified and handled, followed by root-cause analysis and corrective/preventive measures.

APPLICATION / API SECURITY

Security guidance follows the transaction boundary

Production algorithms, exact headers and credential formats are published only when approved.

If the table is wider than its frame, scroll horizontally to see all columns; use arrow keys when the table region has focus.

Security guidance follows the transaction boundary
Control	Developer / operator expectation	Evidence posture
API credential	Store server-side; rotate through approved process	No secret in browser/demo package
Webhook	Verify signature/timestamp where contract defines it	Correlation + delivery log
Replay / duplicate	Use idempotency and event identifiers	Duplicate-safe processing
Logging	Do not log secrets or unnecessary personal data	Correlation without leakage

Scope discipline

Organizational ISO controls do not automatically prove every Sign component implements every control in the same way. Product and deployment evidence remains separate.

ASSESSMENT DETAIL

Security assurance across the service lifecycle

Security assessment of Sign should follow the service lifecycle rather than a static checklist. Before deployment, the organization identifies assets, actors, trust boundaries and integration methods. During operation, access, configuration, audit, monitoring and incident handling are governed by defined roles. When the service changes or ends, credentials, access, data and evidence need to follow the applicable policy.

If the table is wider than its frame, scroll horizontally to see all columns; use arrow keys when the table region has focus.

Security assurance across the service lifecycle
Stage	Control question	Expected evidence
Onboarding	Who is authorized? Which routes and environments are allowed?	Approval, role and configuration records
Runtime	Which requests are authenticated/authorized and which events are auditable?	Transaction, audit and security events
Incident	Who triages, contains, recovers and performs RCA?	Incident and corrective-action records
Change	How are contract, provider, Agent or policy changes controlled?	Version/change evidence
Offboarding	Which credentials, access and data are revoked or retained?	Revocation and retention/disposal records

Assess algorithms, topology, monitoring coverage, service levels and control frequency against deployment evidence. The reference architecture does not establish these operational parameters.

REFERENCE

Control objectives and assessment evidence

If the table is wider than its frame, scroll horizontally to see all columns; use arrow keys when the table region has focus.

Control objectives and assessment evidence
Domain	Relevance to Sign	Evidence required	Limitation
Governance	Policy, risk owners and ISMS scope	ISO / official policy	Requires deployment evidence; cannot be inferred from a certification logo.
IAM	Least privilege, privileged access, review and revocation	Access matrix / access history	Requires deployment evidence; cannot be inferred from a certification logo.
Data protection	Classification, purpose, retention and access	Data policy / deployment record	Requires deployment evidence; cannot be inferred from a certification logo.
Application security	Bind documents, sessions, redirects and callbacks	Design / assessment results	Requires deployment evidence; cannot be inferred from a certification logo.
Secure development	Change review, dependencies and vulnerability handling	Release / test records	Requires deployment evidence; cannot be inferred from a certification logo.
Monitoring	Track failures, states and correlation	Redacted logs / alerts	Requires deployment evidence; cannot be inferred from a certification logo.
Incident response	Triage, contain, recover and notify	Incident / exercise records	Requires deployment evidence; cannot be inferred from a certification logo.
Continuity	Failover, recovery and uncertain-state reconciliation	Plan / recovery evidence	Requires deployment evidence; cannot be inferred from a certification logo.
Supplier	CA/RSSP, identity and billing boundaries and responsibilities	Contract / responsibility matrix	Requires deployment evidence; cannot be inferred from a certification logo.
Audit	Connect actors, documents, decisions and outcomes	Transaction evidence / review records	Requires deployment evidence; cannot be inferred from a certification logo.

Security Architecture

Private-key operations remain within the applicable signing infrastructure.

Separate control from execution.

GoPaperless

Agent / Mobile

CA/RSSP

Security architecture starts with boundaries and abuse cases

Eight domains instead of a generic “secure by design” statement

Security Governance & ISMS

Asset Management

Identity & Access

System & Data Protection

Application & API Security

Monitoring & Incident Response

Personnel Awareness

Audit & Improvement

From event to root-cause evidence

Security guidance follows the transaction boundary

Security assurance across the service lifecycle

Control objectives and assessment evidence

Related content