REDCap: Secure Research Data Capture

• REDCap is a web-based research management application that supports secure, structured data collection for diverse study designs including clinical trials and retrospective studies.
• It provides configurable data collection instruments, API integrations, role-based access control, and audit logging to meet HIPAA, GDPR, and FDA compliance.
• Security in REDCap is enhanced through multi-factor authentication, encryption, input validation, and can be augmented with blockchain-based provenance systems like Scrybe.

Research Electronic Data Capture (REDCap) is a widely used web-based research management application (RMA) developed by Vanderbilt University for secure, structured data collection and management in clinical and translational research. It supports a range of study designs—clinical trials, retrospective studies, cohort studies—and is deployed across multi-site and international projects. In practice, REDCap sits at the intersection of electronic data capture, research operations, and regulated information governance: it provides configurable data collection instruments, programmatic interfaces, role-based project administration, and audit-oriented workflows for data that commonly include Protected Health Information (PHI), personally identifiable information (PII), and study-specific measurements (Sindala et al., 3 Oct 2025).

1. Scope, functions, and research workflows

REDCap’s core function is secure, structured data collection and management. Its workflow surface includes configurable data collection instruments, surveys and forms with branching logic and validation, automated reminders and alerts, real-time monitoring, data export to statistical tools, EHR integrations, multilingual and multi-site support, and mobile/offline data collection (Sindala et al., 3 Oct 2025). In operational terms, REDCap provides web-based project setup, instrument builders for case report forms and surveys, and data dictionaries that can be reused across institutions. It supports online designers and offline CSV “data dictionary” imports, as well as validation, range checks, repeatable instruments and events, longitudinal study support, and multi-center data access groups (Oakley et al., 2021).

Within project administration, REDCap uses role-based access control with granular rights, data access groups to segment centers, and administrative controls. Programmatic access is provided through a token-based HTTP POST API for import and export of records, files, and metadata, and that API is frequently used by mobile applications and external integrations (Oakley et al., 2021). Institutional credentials, sponsor-based external collaborator onboarding, and project-level privilege configurations form part of the access model described for deployed environments (Sindala et al., 3 Oct 2025).

The platform’s breadth of use in clinical and translational research has a direct security consequence: the same workflows that make REDCap useful for distributed studies also create multiple ingress, egress, and trust-boundary transitions. This suggests that REDCap is best understood not merely as a form builder or data repository, but as a research-system hub whose security posture depends on interactions among user endpoints, network paths, databases, mobile clients, and external systems.

2. System architecture and data flow boundaries

The security analysis models REDCap as an RMA composed of a web application, an application/API layer, a backend database, and storage. The web application includes browser-based researcher and participant interfaces, survey links, and a mobile app. Programmatic access is exposed through APIs for data import/export and user/project management, and REDCap integrates with external systems such as EHRs. The mobile application enables offline capture with later synchronization to the central server (Sindala et al., 3 Oct 2025).

The corresponding data flow is straightforward at a high level but security-relevant in detail. User inputs enter through the web interface or mobile app, traverse network links to the application server, are processed, persisted in the database, and then accessed for analysis and export. The analysis identifies several vulnerability classes along this path: unvalidated inputs leading to SQL injection at the database layer; unencrypted or inadequately protected transmission between client and server, making interception or man-in-the-middle attacks plausible; processing points vulnerable to buffer overflows or code injection; and API integrations that act as potential ingress and egress points requiring robust protocol protections (Sindala et al., 3 Oct 2025).

The paper emphasizes trust boundaries at login and authentication flows, public survey links versus authenticated project access, browser-to-server TLS handshakes, server-to-database connections, outbound and inbound API messages to external systems, and the offline mobile app during synchronization. For these protocol interactions it applies the Dolev–Yao adversary model, assuming an attacker can intercept, inject, replay, or delete messages, and can decrypt if keys are compromised (Sindala et al., 3 Oct 2025). A plausible implication is that REDCap’s effective attack surface is determined not only by its own code paths, but also by how institutions expose public surveys, configure APIs, and secure synchronization between disconnected devices and central infrastructure.

3. Security controls and threat modeling

The security analysis evaluates REDCap and similar RMAs using both MITRE ATT&CK and STRIDE. The ATT&CK tactics and techniques enumerated for this environment include Initial Access through Phishing and Exploit Public-Facing Application; Execution through Command and Scripting Interpreter and PowerShell; Privilege Escalation through Exploitation and Bypass UAC; Defense Evasion through Obfuscated Files and Disable Security Tools; Credential Access through Credential Dumping and Brute Force; Discovery through System Information Discovery and Network Service Scanning; Lateral Movement through Remote Services (RDP/SSH) and Pass the Hash; Collection through Data from Local Systems and Input Capture; Exfiltration through Over C2 channel and Automated Exfiltration; and Impact through Data Destruction and Ransomware (Data Encrypted for Impact) (Sindala et al., 3 Oct 2025).

Under STRIDE, the mapped examples are credential theft or token replay to impersonate users for Spoofing, unauthorized updates to manipulate research results for Tampering, log manipulation to hide actions for Repudiation, improper access control exposing sensitive data for Information Disclosure, flooding the web server to disrupt availability for Denial of Service, and exploitation of vulnerabilities to obtain admin rights for Elevation of Privilege (Sindala et al., 3 Oct 2025). These categories matter in REDCap because the platform combines public-facing endpoints, identity-bearing sessions, back-end data manipulation, and high-value regulated records.

Observed or recommended controls correspond to these threat classes. Encryption in transit and at rest is emphasized; the extended analysis treats TLS handshakes and API key exchanges as core protocol-level protections and recommends formal verification with ProVerif to ensure secrecy, authentication, and integrity properties. At the database and application boundary, strict input validation and sanitization, least-privilege database connectivity, whitelisting, patching, continuous monitoring, anomaly and malware detection, and firewalls are all identified as essential measures. At the authorization layer, project-level role-based permissions are supplemented by recommendations for least privilege and microsegmentation to reduce blast radius. Audit logging and auditing support accountability, tamper detection, and repudiation defenses, while regular updates, endpoint detection and response, and backup strategies are presented as defense-in-depth controls (Sindala et al., 3 Oct 2025).

A common misconception is that a secure data capture platform is secure by default once installed. The threat model does not support that view. It identifies residual risks concentrated at public survey links, participant endpoints, external API and EHR integrations, offline mobile synchronization, misconfiguration, and missing MFA. The cited healthcare breach example involving approximately 190M PHI exposed through a remote access portal lacking MFA is used specifically to show that identity-control failures can dominate overall system risk even when application-layer functionality is otherwise mature (Sindala et al., 3 Oct 2025).

4. Audit logging, provenance, and non-repudiation

REDCap includes native audit capabilities. It provides computer-generated logs of create, update, and delete actions, report creation, exports, and some administrative events, and those logs are stored in the underlying relational database. This supports accountability and operational review, and in conventional deployments it is part of a broader stack that may include secure institutional data centers, backups, redundancy, SSL/TLS, and HIPAA-supporting configurations (Oakley et al., 2021).

However, the native audit model has explicit limitations in modern multi-source pipelines. Because REDCap logs reside in the same administrative domain as the database, they can be exposed to infrastructure compromise or privileged tampering. They are not cryptographically anchored to an append-only ledger. Native logs also do not provide cryptographic chain-of-custody across context-aware devices, mobile apps, and multiple ingest systems; they do not natively hash and sign record states or field-level values; and they do not produce cryptographic proofs that can be independently verified against an immutable ledger. The paper further notes that REDCap does not itself guarantee device source validity or firmware attestation for IoT sensors, instead trusting data delivered through the API or user interface (Oakley et al., 2021).

These limitations motivate external provenance systems such as Scrybe, a permissioned blockchain proposed to store proof of clinical trial data provenance and demonstrated through a proof-of-concept integration with REDCap (Oakley et al., 2021). In that design, a Python script ingests CSV data, calls REDCap’s API to create or update records, writes a changelog entry on an institutional server, and submits a blockchain transaction containing the hash of the changelog entry and non-identifying metadata. Verification tools then compare the entire changelog and blockchain to detect corruption. The formal cryptographic description includes hashing $h = H(m)$, a signature scheme

$$\text{KeyGen} \to (sk, pk), \quad \text{Sign}(sk, m) \to \sigma, \quad \text{Verify}(pk, m, \sigma) \to \{0,1\},$$

and chain-of-custody anchoring

$t_k = H(t_{k-1} \,\|\, e_k),$

where $e_k$ is an event record (Oakley et al., 2021).

This suggests a useful distinction between operational auditability and cryptographically independent auditability. REDCap natively supports the former through database-resident logs and administrative controls. Scrybe is presented as an augmentation for the latter, particularly when sponsors require independent verification outside the REDCap administrative domain, stronger non-repudiation, or provenance across wearables, context-aware devices, and heterogeneous ingest pipelines.

5. Confidentiality, integrity, availability, and authentication in regulated environments

The security analysis evaluates REDCap against confidentiality, integrity, availability, non-repudiation, and authentication. Confidentiality is tied to encryption for data in transit and at rest, access controls, and least privilege. Integrity is tied to input validation, restricted database channels, and cryptographic integrity checks such as hashes and digital signatures. Availability is tied to denial-of-service protections including rate limiting and traffic filtering, redundancy and load balancing, robust backup and restore strategy, and ransomware response. Non-repudiation is supported through audit logging and immutable records of user actions, while protocol authentication properties are treated as supporting provenance and non-repudiation. Authentication relies on institutional credentialing and project-level role-based access, with mandatory MFA presented as the core recommendation and Zero Trust extending that model to continuous authentication and device posture checks (Sindala et al., 3 Oct 2025).

Regulatory alignment is discussed in terms of HIPAA, GDPR, and FDA expectations. REDCap is described as designed to support HIPAA/GDPR-aligned operations, including privacy, data minimization, and secure handling of PHI and PII. The analysis also notes evolving GDPR and HIPAA expectations, including explicit consent, tensions between the right to erasure and long-term research retention, and the role of de-identification and pseudonymization. For FDA and 21 CFR Part 11, the discussion emphasizes traceability and accountability for each data point, as well as the need for institutions to enforce validation of electronic systems, audit trails, access governance, and controlled records (Sindala et al., 3 Oct 2025).

The Scrybe paper develops this compliance theme at a finer granularity. It maps technical mechanisms to Part 11.10 controls, including system validation, generation of accurate and complete copies for inspection, protection of records for retrieval throughout the retention period, limitation of system access to authorized individuals, and secure, computer-generated, time-stamped audit trails that do not obscure previously recorded information. It also maps to ISO 27789 requirements for time-stamped, user-attributed, non-modifiable audit trails and verification procedures (Oakley et al., 2021). Importantly, both sources are explicit that technical controls are not the entire compliance program. Sponsor standard operating procedures, computerized system validation, quality assurance, retention governance, and institutional security operations remain necessary.

6. Risk assessment, hardening, and operational limits

The risk assessment framework is qualitative, centered on impact and likelihood, and prioritizes high-impact scenarios such as PHI exfiltration and ransomware. The analysis states that this is consistent with standard formulations:

$R = P \times I$

for overall risk and

$E[L] = \sum_i p_i \cdot I_i$

for expected loss across scenarios. These formulas can be applied to REDCap by estimating the probability $p_i$ of attack classes and the impact $I_i$, such as number of records, regulatory penalties, or downtime (Sindala et al., 3 Oct 2025). The case reference to approximately 190M PHI exposed due to missing MFA is used to underscore that identity-control failures may carry very high impact even when attack probability is only moderate (Sindala et al., 3 Oct 2025).

The hardening guidance is correspondingly identity-centric and defense-in-depth oriented. Recommended measures include MFA everywhere, SSO with strong password policies, monitoring of privileged accounts, Zero Trust Architecture with continuous authentication and authorization, microsegmentation, least privilege, isolation of database servers from admin workstations, context-based access decisions, regular security updates to operating systems, web servers, REDCap application code, libraries, and plugins where applicable, and robust input validation and API hardening with scoped tokens, strict schemas, and replay protections. The same guidance also emphasizes monitoring, alerting, IDS/IPS, endpoint detection and response, offline or segmented backups, tested restorations, network segmentation, secure management of API keys and certificates, incident response playbooks, and continual user training on phishing, survey links, mobile synchronization, and data exports (Sindala et al., 3 Oct 2025).

Two limitations recur across the literature. First, there is no quantitative benchmark set in either source for end-to-end REDCap security performance. The extended security analysis qualitatively states that email filtering and training “greatly reduce phishing incidents,” microsegmentation “significantly reduces lateral movement,” and ML-based exfiltration and malware detection achieves “high success rates,” but does not publish numeric benchmarks (Sindala et al., 3 Oct 2025). Second, native REDCap functionality, while substantial, does not by itself provide cryptographically anchored, independently verifiable provenance across heterogeneous sources. Scrybe addresses that specific gap, but introduces additional operational complexity in the form of keys, nodes, governance, integration effort, and the need for validation and standard operating procedures (Oakley et al., 2021).

A further misconception is that compliance-grade auditability necessarily requires replacing REDCap. The papers do not support that conclusion. A more precise reading is that REDCap can support confidentiality, integrity, availability, non-repudiation, and authentication requirements when paired with strong institutional controls, and that external provenance mechanisms such as Scrybe are best interpreted as augmentations for settings with multi-source pipelines, heightened provenance requirements, or elevated insider-tampering risk (Sindala et al., 3 Oct 2025).

7. Position within contemporary research data infrastructures

Within contemporary research infrastructures, REDCap occupies a hybrid role: it is simultaneously an electronic data capture environment, a study operations platform, an integration point for EHR and API-based workflows, and an administrative boundary for regulated data. Its strengths include configurable instruments, survey and longitudinal support, role-based project controls, mobile and offline capture, exports for downstream analysis, and broad suitability for clinical and translational research programs (Sindala et al., 3 Oct 2025).

Its structural weaknesses, as identified in the literature, are not unique to REDCap but characteristic of RMAs more generally. These include exposure at public-facing application boundaries, dependence on institutional identity and network governance, sensitivity to misconfiguration, and the difficulty of guaranteeing end-to-end provenance when data arrive from sensors, mobile apps, and external ingest systems. The extended security analysis therefore frames REDCap inside a broader modern RMA threat landscape and recommends identity-first, protocol-secure, and defense-in-depth mitigations. The Scrybe work, by contrast, focuses on one particularly narrow but important deficiency: the gap between conventional database-resident audit logs and immutable, independently verifiable provenance suitable for 21 CFR Part 11 and ISO 27789-oriented scrutiny (Sindala et al., 3 Oct 2025, Oakley et al., 2021).

Taken together, these analyses position REDCap as a mature and widely deployed research management application whose practical security and compliance posture depends less on any single feature than on the surrounding institutional architecture. With enforced MFA, least-privilege RBAC, microsegmentation, validated audit trails, secure APIs, continuous monitoring, and disciplined data lifecycle governance, REDCap can operate as a secure substrate for regulated clinical research. Where independent cryptographic provenance across heterogeneous data sources is required, augmentations such as permissioned-ledger anchoring offer a distinct, complementary control plane rather than a replacement for REDCap’s core data capture functions.